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

Welche Alternative zum Tuxbox-CVS soll in Zukunft zum Einsatz kommen?

CVS soll bleiben
27
21%
SVN
29
22%
GIT
56
43%
CVS+GIT gemeinsame Repos, CVS als HEAD
7
5%
Andere (bitte in deinem Beitrag angeben!)
0
Keine Stimmen
egal
10
8%
 
Insgesamt abgegebene Stimmen: 129

dwilx

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

Beitrag von 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
derget hat geschrieben:...
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.
Zuletzt geändert von dwilx am Mittwoch 18. Februar 2009, 10:10, insgesamt 1-mal geändert.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: CVS: Tuxbox-Releases, HEAD, Experimentier-Branch etc...

Beitrag von 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
Contributor
Beiträge: 1833
Registriert: Mittwoch 10. April 2002, 14:39

Re: CVS: Tuxbox-Releases, HEAD, Experimentier-Branch etc...

Beitrag von 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
Administrator
Beiträge: 2675
Registriert: Donnerstag 28. September 2006, 18:18

Re: CVS: Tuxbox-Releases, HEAD, Experimentier-Branch etc...

Beitrag von 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
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: CVS: Tuxbox-Releases, HEAD, Experimentier-Branch etc...

Beitrag von 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
Administrator
Beiträge: 2675
Registriert: Donnerstag 28. September 2006, 18:18

Re: CVS: Tuxbox-Releases, HEAD, Experimentier-Branch etc...

Beitrag von dbt »

Gibts für git auch eine favorisierte GUI? Habe grad mit gitk experimentiert. Sieht eigentlich ganz gut aus.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: CVS: Tuxbox-Releases, HEAD, Experimentier-Branch etc...

Beitrag von 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
Administrator
Beiträge: 2675
Registriert: Donnerstag 28. September 2006, 18:18

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von dbt »

Boahh, Hast du jetzt den ganzen CVS-Tree auf git portiert?
Edit: oder bist du grade dabei?
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von 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
Contributor
Beiträge: 1833
Registriert: Mittwoch 10. April 2002, 14:39

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von 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
Erleuchteter
Erleuchteter
Beiträge: 595
Registriert: Donnerstag 1. Januar 2004, 16:59

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von prodigy7 »

dietmarw hat geschrieben: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
Administrator
Beiträge: 2675
Registriert: Donnerstag 28. September 2006, 18:18

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von 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
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 13:05

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von 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
seife hat geschrieben: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
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von 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
Administrator
Beiträge: 2675
Registriert: Donnerstag 28. September 2006, 18:18

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von 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
Administrator
Beiträge: 2675
Registriert: Donnerstag 28. September 2006, 18:18

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von dbt »

@seife
seife hat geschrieben: 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 :gruebel:
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
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von seife »

dbt hat geschrieben: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
Administrator
Beiträge: 2675
Registriert: Donnerstag 28. September 2006, 18:18

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von 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
Administrator
Beiträge: 2675
Registriert: Donnerstag 28. September 2006, 18:18

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von 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. :wink:
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von 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
Administrator
Beiträge: 2675
Registriert: Donnerstag 28. September 2006, 18:18

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von 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 :gruebel:
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von 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
Administrator
Beiträge: 2675
Registriert: Donnerstag 28. September 2006, 18:18

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von 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
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von 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
Administrator
Beiträge: 2675
Registriert: Donnerstag 28. September 2006, 18:18

Re: Releases, HEAD, Branches, CVS-Alternative: Git

Beitrag von dbt »

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