[linux-l] Nutzt jemand Git?

Steffen Dettmer steffen at dett.de
So Mai 17 18:52:57 CEST 2009


* olafBuddenhagen at gmx.net wrote on Sat, May 16, 2009 at 06:33 +0200:
> Ich verstehe Dein Szenario ehrlich gesagt nicht so ganz... Aber es
> klingt nach einem Fall fuer "git submodule".

Ja danke! Hab die Überschriften schon mal gelesen, aber das ist
wohl ein komplexeres Thema, dass ich mir erstmal anschauen muß.

> Das funktioniert etwas anders als geschachtelte CVS-Repositories: Bei
> einem Commit wird nicht automatisch in die Unterrepositories comitted.
> Wenn man in einem Unterrepository was aendert, muss man das zunaechst
> dort commiten. Im Haupt-Repository wird dann vermerkt, in welchen
> Versionsstaenden die Unterrepositories jeweils eingebunden werden.

mmm... Das klingt gut. Das klingt, als ob ich sogar ein submodul
zweimal ins gleiche auschecken kann und es geht. Das geht bei CVS
leider nicht, was ein ziemlicher Nachteil ist (wenn ich von einer
lib z.B. zwei Versionen in der Sandbox brauche - mindestens
taggen geht ja dann nicht!).
Spannend. Wenn das Hauptrepo da was intelligentes macht, könnte
das ja funktionieren. Wäre Klasse, wenn git das `nebenbei' lösen
würde. Sowas spricht immer für's Konzept, finde ich.

> der zentrale Server viel weniger kann als die "Clients"... (Vor allem da
> Subversion ja bis vor Kurzem nicht einmal Merge-Tracking hatte -- die
> Informationen fehlen dann einfach.)

na ja, `bis vor kurzem'? Erstmal wird das ja nicht rückwirkend
gehen und zweitens würde ich ja erwarten, dass man dann von SVN
zu SVN migrieren muß! Und wenn man Pech hat, muß man entweder was
an einem fünf Jahre alten SVN Server machen (weils update da
nicht kompiliert) oder vielleicht gar die Clienten updaten... Na
ja, egal.

> git-cvs ist uebrigens nicht sonderlich gut. Es gibt einige anderen
> Import-Tools, die wohl viel mehr fressen koennen...

Na ja, wer weiß, was die dann wieder an Nachteilen haben :(

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.



Mehr Informationen über die Mailingliste linux-l