[Umfrage] CVS-Alternativen: Git, SVN etc...

[dwilx]

Es scheint zu diesem Thema (siehe hier: http://forum.tuxbox-cvs.sourceforge.net ... 81#p364581) Diskussionsbedarf zu bestehen. Ich habe mir deshalb erlaubt hier ein Thema aufzumachen um die Diskussion dort nicht unnötig offtopic ausufern zu lassen. Evtl. ergibt sich etwas daraus.

Jüngstes Beispiel mit der Übernahme von newmake ins HEAD hat gezeigt, dass Branches etwas bringen. Und das nach beachtlichen 3 Jahren!!!
Das Einbringen von Patches hat sich zwar bewährt, birgt aber auch die Gefahr, dass sie irgendwann verstauben, verschwinden, nicht beachtet und nie fertig werden oder nie ins CVS kommen. Das ist leider schon oft passiert. Nur aufmerksame Leute graben dann wieder mal einen guten Patch aus und erst dann bekommt er evtl. Beachtung.
Gut gemeinte Sammelstellen für Patches und Links zu Patches oder Threads wurden immer wieder aufgemacht, sind jedoch nie dauerhaft bestehen geblieben.
Größere Änderungen, wie etwa Portierungen auf auf andere Hardware, oder grundlegende Umstrukturierungen könnten größere Änderungen mit sich bringen, die unter Umständen überdurchschnittlich viele Patches nötig machen und die Sache unübersichtlich wird.

Zum Problem:

• Brauchen wir regelmäßige Releases oder reicht HEAD?
  Wie sinnvoll sind für uns Branches?
  Ist ein Experimentier-Branch die AllInOne-Lösung?
  Welche Vor-oder Nachteile würde das bringen?
  Reicht uns die bisherige reine "Patch-Methode"?
  Wann wäre welche Methode angebracht?
  Wie würde eine Koexisistenz von mehreren Versionsverwaltungssystemen aussehen?
  Geht das überhaupt?
  CVS-Alternative: Git?
  Wie würden die Image-Anbieter das regeln?

Edit: aus aktuellem Anlaß:
http://www.tuxbox-cvs.sourceforge.net/f ... 49#p375049

...
Ich werden das CVS in den nächsten Wochen komplett neu aufsetzten.
Die Frage stellt sich, wollen wir wechseln zu svn oder wat weiss ich.
Macht mal Vorschläge.

[seife]

Also für mich ist die Sache klar: http://gitorious.org/projects/tuxbox-apps enthält meine Sachen. Es wird dort, wenn ich mit GIT etwas besser klar komme, mehrere heads in einem project geben, momentan sind es noch mehrere Projekte, damit ich nicht aus versehen was kaputt mache.
Dort kann sich jeder der will die Patches rauspicken, die ihm Gefallen, wer will kann sie auch ins CVS einchecken. Dank obi landen sie dann via git.opendreambox.org auch wieder in meinen Trees.

Der Vorteil für mich ist:
- Ich kann radikal ändern und kaputtmachen, was ich will.
- Ich kann implementieren was ich will.
- Für geht der Aufwand mindestens um die Hälfte zurück (bisher habe ich imer mehr als 4 CVS-Trees synchronisieren müssen: dbox-2.4, dbox-2.6, dm500, i586, td)
- Ich muss mich nicht genauer ins CVS einarbeiten (tote Pferde soll man nicht unnötig lange reiten).
- Ich lerne an einem unkritischen Projekt, git zu benutzen (das brauche ich sowieso)

Der Vorteil für andere ist:
- alle meine Patches, welche ich lokal verwende, werden nun öffentlich (nicht alle sind nützlich)
- es ist trivial, seinen eigenen git clone zu haben und einzeln Patches von mir zu importieren
- wenn jemand mitarbeiten will, kann er ganz einfach seinen eigenen git-tree zum pull anbieten.

Anfangs wirds etwas holprig sein, weil ich mich selbst mit git noch nicht wirklich auskenne, aber das muss ich sowieso lernen, insofern ist die Gelegenheit günstig.

Insofern ist es mir relativ egal, ob hier nun beschlossen wird, dass stabile releases benötigt werden oder dass CVS HEAD immer funktionieren muss... ;-)

[dietmarw]

wäre es nicht sinnvoller einmal den schritt auf ein neues versions verwaltungssystem zu machen
als sich ständig über das veraltete cvs und sein begrenzten möglichkeiten zu ärgern??

[dbt]

Von Git hört man eigentlich viel Gutes. Das mag auch zutreffen. Genauer hab ich mir das bisher nicht angesehen, aber auf den ersten Blick erschlägts einen aber, weil's doch teilweise ganz andere Ansätze hat.
So wie ich das verstehe gibt es kein zentrales Repsitory und jeder hat eine eigene Kopie, alles läuft irgendwie unabhänig voneinander. So ganz verstehen nicht wie dann was fertiges in Form von Releases und ein vergleichbares CVS-Head rauskommen soll. Das hat irgendwie den Charme einer Tauschbörse ala EMule.

[seife]

Randal Schwartz (Der von "Learning Perl") hat git ganz nett in einem Google Techtalk erklärt:
http://de.youtube.com/watch?v=8dhZ9BXQgc4

[dbt]

Gibts für git auch eine favorisierte GUI? Habe grad mit gitk experimentiert. Sieht eigentlich ganz gut aus.

[seife]

keine Ahnung, ich brauchte bisher nicht mehr als

* git clone - einmal das repository "auschecken"
* git pull - Änderungen von upstream holen, "cvs update"
* git add - geänderte Dateien zum checkin markieren
* git commit - markierte dateien "einchecken" (lokal)
* git push - Änderungen publizieren
* git checkout -b - Branch anlegen
* git checkout - Branch "wechseln"
* git diff (--cached) - Änderungen anschauen
* git log

(ausserdem noch "git rebase", aber das ist wohl mit Vorsicht zu geniessen und das braucht man nur, wenn man mehrere Branches hat, die aufeinander aufbauen).

Ich habe aber auch für CVS nur selten eine GUI benutzt

[dbt]

Boahh, Hast du jetzt den ganzen CVS-Tree auf git portiert?
Edit: oder bist du grade dabei?

[seife]

Ich habe ihn halt importiert. Nachdem Obi's Tree den gleichzeitigen Commit von controld-zapit-merge und Houdini's LCD-Fix nicht richtig mitbekommen hat, habe ich halt einen eigenen Import gemacht (und das problematische changeset von Hand eingecheckt)

Das ist aber nur dazu, damit ich das (zum diff-en etc) mal schnell in einen temporären Branch fetchen kann.

[dietmarw]

da es ja so aussieht, als würden größere änderungen der supporteten modelle
ins haus stehen (danke an die mitwirkenden), hier noch einmal meine ernst gemeinte frage:

-wäre jetzt nicht ein günstiger zeitpunkt cvs vorher den rücken zu kehren?
-es gibt eigentlich nur noch eine handvoll wirklich regelmäßig aktiver entwickler,
mal "butter bei die fische".. was würde dagegen sprechen wenn die nutzung
des neuen repositorys für den "normalgebrauch" vernünftig dokumentiert wäre?
(also der checkout und commit)

[prodigy7]

was würde dagegen sprechen wenn die nutzung
des neuen repositorys für den "normalgebrauch" vernünftig dokumentiert wäre?
(also der checkout und commit)

Wäre dafür! Für jemand, der nicht gleich

Code: Alles auswählen

make all

beim bauen eingibt, sollte so etwas dokumentiert sein - würde einiges vereinfachen und man müsste sich nicht mühseelig alles zusammensuchen hier im Forum.

[dbt]

Also ich bin seit einiger Zeit mit Git am werkeln und mehr oder weniger in der Probierphase, aber bin ziehmlich angetan von den Möglichkeiten, die git bietet. Das ist zwar eine komplette Umstellung was das Konzept angeht. Wenn man aber CVS oder SVN dagegen stellt, leuchtet einem ein, weshalb man über z.B. CVS nur noch lächeln kann. Ich hab auch schon überlegt im Wiki etwas über's auschecken einzuschreiben. Eine kurze Anmerkung dazu wurde ja schon kürzlich gemacht, seh' ich grade.
http://wiki.tuxbox-cvs.sourceforge.net/ ... sdir.3DDIR
Es gibt auch für git einige Erweiterungen um auch mit einem CVS-Rep zu arbeiten (git-cvs), das habe ich aber bisher noch nicht probiert, evtl. kann Seife dazu etwas näher eingehen.
Edit. Tuxbox-CVS hat Seife wie schon erwähnt ja bereits übernommen. In wie weit das schon nutzbar wäre, weiß ich so nicht, Seife?

[rhabarber1848]

Auch auf die Gefahr hin nun als Spielverderber zu gelten, sehe
ich den akuten Bedarf für eine Alternative zu CVS nicht.

Seife arbeitet gut mit seinem Git-Repo
http://forum.tuxbox-cvs.sourceforge.net ... 53#p366353

Ja, "git cherry-pick" und "git cvsexportcommit" rocken wirklich ;-)

was aber seine persönliche Entscheidung ist.

Für den Normalbetrieb halte ich CVS für vollkommen
ausreichend, besonders im Hinblick auf die Tatsache,
dass wir eher weniger Branches (dreambox) haben
werden als mehr.

[seife]

Das tuxbox-cvs git repo ist soweit schon nutzbar, allerdings wird es von mir manuell updated, also immer dann, wenn sich im tuxbox-cvs was getan hat, stosse ich das update manuell an, es kann also etwas out-of-date sein, wenn ich mal ein paar Tage nicht dazu komme.

Was bei diesem git-repo anders ist: für jedes CVS-Modul (apps/ cdk/ driver/...) gibt es ein eigenes repo. Das ist IMHO übersichtlicher, ausserdem benutze ich ja das apps/-Zeug unabhängig vom tuxbox-CDK.

Worüber man sich klar sein muss: das Entwicklungsmodell mit git ist radikal anders als mit CVS. Es gibt kein zentrales repository, jeder Entwickler hat seinen eigenen Tree, kann sich aber einfach von den anderen die Änderungen abholen.

Insofern finde ich es gar nicht so verkehrt, das tuxbox-CVS als zentales "Master"-repo für user zu behalten. Mit git-cvs ist es wirklich einfach, einzelne Patches (oder auch ganze serien, halt patch für patch) aus einem git repo ins CVS zu exportieren, insofern ist das für die Entwickler nicht viel zusätzliche Arbeit und für die User, die "nur" den funktionierenden aktuellen Code haben wollen ist es ok. Das CVS wäre sozusagen der "stabile branch", jeder der am Code entwickelt hat seine eigenen git-repo(s), die Entwickler können untereinander über ihre git-repos komfortabel Code austauschen und wenn man feststellt, dass ein Feature "gut genug" oder ein bugfix wichtig genug ist, dann wird er ins CVS exportiert.

Man darf dabei auch nicht vergessen, dass das tuxbox-CVS seit Jahren relativ zuverlässig und kontinuierlich von derget gehostet wird, vor man da was umschmeisst, sollte man gut überlegen, wozu und warum und wie.

Wenn nach $ZEIT alle feststellen, dass das mit git alles viel besser und einfacher ist, dann kann man dann immer noch ein master-git-repo aufmachen, das das CVS dann ablöst.

Achso: "interessierte Nutzer" gelten in der Beschreibung oben auch als "Entwickler" bzw. "...die am Code entwickeln" und vermutlich würde es dann schon mal heissen "checke mal meinen git-branch foo von http://bar aus, da ist der bug wohl schon gefixt" um was zu testen, aber das sollte für die Leute, die soweit sind, dass sie patches testen können, auch keine grosse Hürde mehr sein.

Ich werde demnächst mal ein "tuxbox development with git"-Dokument schreiben, wo drinsteht, wie ich das normalerweise so mache, das zeigt evtl. auch, was möglich ist (evtl. sieht dann auch jeder, dass ich das total "falsch" mache und gibt mir Tipps, wie's besser geht )

Jetzt wo ich den post fertig habe, sehe ich rhabarber's post und wie ihr seht, stimme ich ihm 100% zu

[dbt]

Insofern finde ich es gar nicht so verkehrt, das tuxbox-CVS als zentales "Master"-repo für user zu behalten. Mit git-cvs ist es wirklich einfach, einzelne Patches (oder auch ganze serien, halt patch für patch) aus einem git repo ins CVS zu exportieren, insofern ist das für die Entwickler nicht viel zusätzliche Arbeit und für die User, die "nur" den funktionierenden aktuellen Code haben wollen ist es ok. Das CVS wäre sozusagen der "stabile branch", jeder der am Code entwickelt hat seine eigenen git-repo(s), die Entwickler können untereinander über ihre git-repos komfortabel Code austauschen und wenn man feststellt, dass ein Feature "gut genug" oder ein bugfix wichtig genug ist, dann wird er ins CVS exportiert.

Dem stimme ich auch 100% zu. Das hat auf jeden Fall Sinn. Eine komplette Umstellung wäre m.M. nach auch zu radikal, weil es doch für eingefahrene cvs-Nutzer wahrscheinlich zu viel des Guten wäre. Das wäre ungefähr so als steigt man vom Fahrrad auf eine Luxuskarosse um.

[dbt]

@seife

Ich werde demnächst mal ein "tuxbox development with git"-Dokument schreiben, wo drinsteht, wie ich das normalerweise so mache, das zeigt evtl. auch, was möglich ist (evtl. sieht dann auch jeder, dass ich das total "falsch" mache und gibt mir Tipps, wie's besser geht )

Kleine Zwischenfrage:
Wie machst du das eigentlich mit dem cvsimport?
Ich hatte das damit für mich mal gemacht:

Code: Alles auswählen

git cvsimport -p -v -d [user]@cvs.tuxbox.org/cvs/tuxbox apps

Es ging allerdings nicht mit anoncvs, scheint wohl so üblich zu sein. In dem Fall wäre man wohl auf ein bereits importiertes Repo angewiesen, wo man das mit git clone nach belieben ziehen kann.

Also soweit hat das auch importiert. Hat sich übrigens ziemlich gezogen
Habe das dann so weiter local verarbeitet:

Code: Alles auswählen

mkdir project
cd project
git init
git config user.name "me"
git config user.email "me@my.server"

und damit ich das auf den server bekomme:

Code: Alles auswählen

git remote add origin ssh://me@my.server/gitroot/project/apps
git config branch.master.remote origin
git config branch.master.merge refs/heads/master
git push origin master

Wie läuft das dann mit einem Update? Das gleiche nochmal oder gibt es was spezielles zu beachten besonders wenn man eigene Änderungen vorgenommen hat? Kann sich das nicht beißen? Ich hoffe du kannst etwas helfen. Das cvs git hin und her gezippel ist auf Dauer etwas anstrengend und würde das zumindest für meine Zwecke vereinheitlichen, damit ich local und serverseitig nicht mehr direkt auf cvs angewiesen bin.

[seife]

Kleine Zwischenfrage:
Wie machst du das eigentlich mit dem cvsimport?

ich habe eine handvoll import-skripten, z.b.:

Code: Alles auswählen

seife@server:/local/seife/git> cat import-apps-and-cdk.sh
#!/bin/sh
for MOD in cdk apps; do
        git cvsimport -C tuxbox-$MOD -i -A /local/seife/git/authorconv -a -k -v \
                -d /local/mirror/tuxbox-cvs $MOD
done

Ich habe lokal in /local/mirror/tuxbox-cvs einen rsync-mirror des CVS-Trees vom Server, das macht alles wesentlich einfacher (man darf nur nie dorthin committen )

pushen nach gitorious mache ich mit:

Code: Alles auswählen

seife@server:/local/seife/git> cat push-apps-and-cdk.sh
#!/bin/bash
for repo in apps cdk; do
        git --git-dir=$PWD/tuxbox-${repo}.git push --mirror git@gitorious.org:tuxbox-cvs/$repo.git
done

Wann immer sich was getan hat im CVS rsync'e ich die Änderungen nach /local/seife/mirror, dann rufe ich import-apps-and-cdk.sh auf, dann push-apps-and-cdk.sh. Fertig.

Du musst es auch nicht nochmal selbst importieren, du kannst einfach die einzelnen Module bei mir pullen, das sollte wesentlich schneller gehen

Wie läuft das dann mit einem Update? Das gleiche nochmal oder gibt es was spezielles zu beachten besonders wenn man eigene Änderungen vorgenommen hat? Kann sich das nicht beißen? Ich hoffe du kannst etwas helfen. Das cvs git hin und her gezippel ist auf Dauer etwas anstrengend und würde das zumindest für meine Zwecke vereinheitlichen, damit ich local und serverseitig nicht mehr direkt auf cvs angewiesen bin.

Das cvsimport macht an der Stelle weiter, an der es zuletzt aufgehört hatte. Es macht also automatisch ein "update".

Ich habe für mich halt die "reinen" CVS-imports, die auch auf http://gitorious.org/tuxbox-cvs zu haben sind, in die kommt immer nur der CVSimport rein, da committe ich nie etwas direkt hinein.

Dann gibt es mein "Arbeitsrepo" git://gitorious.org/tuxbox-apps/mainline.git, und dort insbesondere der Branch "tripledragon", in dem ich alle neuen Sachen ausprobiere. Wenn ich etwas für "upstream-fähig" halte, exportiere ich es mit "git cvsexportcommit" in mein lokal ausgechecktes CVS-repo (in dem sonst keine Änderungen drin sind), baue es um zu testen, ob es auch standalone funktioniert und committe es dann ins CVS. Über den CVSimport kommt es dann auch wieder in den tripledragon-Branch zurück, (das mache ich mit "fetch -n /local/seife/git/tuxbox-apps master:cvs.tuxbox-cvs.sourceforge.net; git merge cvs.tuxbox-cvs.sourceforge.net", also ich hole mir die "CVS-Version" in einen lokalen branch cvs.tuxbox-cvs.sourceforge.net und merge dann diesen Branch).

Der Einige Nachteil von meinem Vorgehen ist der, dass im tripledragon-Branch oftmals commits zweimal drin sind, einmal von meinem originalen commit in den tripledragon-Branch, dann werden sie in der History nochmals aufgelistet, wenn sie übers CVS zurückkommen, weil sie dann mit anderer Email und anderem Datum drin sind (der Inhalt ist gleich). Aber damit kann ich leben.

[dbt]

Danke für die Tipps.
Wenn ich das also jetzt richtg verstanden habe, darf man möglichst nicht auf diesen Import-CVS-Tree (master) committen, sondern legt lieber einen Branch an und merged das regelmäßig. Ich habe allerdings mehr aus Versehen einen commit darauf gemacht, funktioniert aber trotzdem noch. Da ist aber noch kein Branch angelegt, so dass falls irgendwas zurückkommen würde, nicht viel passieren kann.

Ich habe das jetzt mit meinem sourcforge account mal probiert, also importiert habe ich local in ein dafür vorgesehenes Verzeichnis und habe das mit dem server repo abgestimmt, indem man das einfach pusht, soweit klappt das auch ganz gut. Das könnte man sogar direkt auf dem Server machen, dazu noch automatisiert mit cronjob, wenn es sein müsste, aber da stört mich eigentlich nur die Abfrage der Zugangsdaten. Dann wäre die Sache fast zeitglich 1:1 am laufen. Dafür fehlt mir aber nur noch die richtige Idee wie man das scripttechnisch machen könnte.

[dbt]

Nächste Frage bezüglich cvs-commits. Dafür wird doch normalerweise git cvsexportcommit verwendet. Sehe ich das richtig, dass man das local machen muss, also ein cvs-Repo auscheckt und mit git cvsexportcommit dorthin merged und erst dann vom cvs-repo wie gewohnt eincheckt oder das über ensprechende Optionen automatisch comitten kann. Laut git cvsexportcommit --help geht das einzeln oder automatisch für mehrere Änderungen, oder wie gehst du genau vor? Man will ja nichts kaputt machen.

[seife]

Ich mach das so:

* tripledragon ist mein "haupt-branch".
* /local/seife/git/tuxbox-apps ist ein clone von git://gitorious.org/~seife/tuxbox-cvs/apps.git
* /local/seife/src/tuxbox-devel ist ein ausgechecktes CVS.

zuerst hole ich mir das "original-CVS" in mein repo:

Code: Alles auswählen

seife@server:/local/.../apps> git fetch -n /local/seife/git/tuxbox-apps master:cvs.tuxbox.org

Jetzt habe ich einen branch "cvs.tuxbox-cvs.sourceforge.net" und kann z.B. mittels "git diff cvs.tuxbox-cvs.sourceforge.net tripledragon" einen diff ziehen.
Ich mache mir noch eine Kopie von "cvs.tuxbox-cvs.sourceforge.net" mit dem Namen "cvstmp":

Code: Alles auswählen

git checkout cvs.tuxbox.org
git checkout -b cvstmp

Jetzt suche ich mir den commit aus dem log, den ich gerne ins CVS committen würde:

Code: Alles auswählen

git log tripledragon

Die commit-ID kopiere ich mir, dann (im cvstmp-branch)

Code: Alles auswählen

git cherry-pick a1b2c3d4 # hier die commit-id einsetzen

Jetzt hat der Commit im cvstmp Branch eine eigene Commit-ID. Wird auch angezeigt nach dem cherry-pick.
Jetzt exportiere ich den Patch:

Code: Alles auswählen

git cvsexportcommit -w /local/seife/src/tuxbox-devel/apps/ 86bc0f6
# die ID die bei cherry-pick angezeigt wurde

Und committe:

Code: Alles auswählen

cd /local/seife/src/tuxbox-devel/cdk
make neutrino
# wenn es funktioniert hat...
cd ../apps
cvs commit -F .msg 'tuxbox/neutrino/src/driver/lcdd.cpp'

Die "cvs commit..."-Zeile wird einem von git cvsexportcommit zum copy'n'paste angezeigt.

Dann importiere ich das CVS wieder zurück in den git-tree git://gitorious.org/~seife/tuxbox-cvs/apps.git, gehe zurück in das Verzeichnis, wo der "cvstmp" Branch noch ausgecheckt ist, mache wieder "git fetch -n..." um den cvs.tuxbox-cvs.sourceforge.net auf den aktuellen Stand zu bringen. "git diff cvstmp cvs.tuxbox-cvs.sourceforge.net" sollte nun nichts mehr anzeigen.
Dann "git checkout tripledragon" und "git merge cvs.tuxbox-cvs.sourceforge.net", damit im tripledragon branch auch alles genau so wie im CVS ist. Fertig.

Anstelle "tripledragon" nimmst du halt deinen "master" oder was auch immer.

[dbt]

Danke, im großen und ganzen gehts. Ich hab nur irgendwie ein Problem mit ssh. Teilweise würde ich einiges automatisieren, aber ich bekomme die Passwortabfrage vom cvs nicht weg

[seife]

einen key generieren (mit passphrase!), auf den CVS-Server kopieren, fertig.
Dann den ssh-agent benutzen, um auch ohne Eingabe der passphrase committen kannst.

Funktioniert bei mir wunderbar

[dbt]

So hatte ich mir das auch gedacht. Aber etwas haut nicht hin.
Erzeuge mir die Keys mit

Code: Alles auswählen

ssh-keygen

und mache die Eingaben für Passphrase usw. Dann raufkopieren:

Code: Alles auswählen

ssh user@ssh-server "mkdir ~/.ssh; chmod 0655 ~/.ssh"
scp ~/.ssh/id_rsa.pub ssh-server:~/.ssh/authorized_keys

ssh agent läuft

Code: Alles auswählen

eval `ssh-agent`

Code: Alles auswählen

ssh-add -l

...zeigt mir jede menge Zeug an, aber jedes login muss mit Passwort erfolgen

Edit: jetzt das noch:

Code: Alles auswählen

Received disconnect from 82.149.243.100: 2: Too many authentication failures ...

[seife]

keine Ahnung. Bei mir funktioniert's

Ich habe allerdings einen RSA und einen DSA-Key in meiner authorized_keys

Achso, und ~/.ssh hat bei mir 0700, nicht 0655, authorized_keys ist 0600

[dbt]

So, wow jetzt rennts, hat wohl an den Rechten gelegen. Danke für den Wink