[linux-l] Nutzt jemand Git?

[Steffen Dettmer]

* Christoph Biedl wrote on Tue, May 05, 2009 at 01:42 +0200:
> Steffen Dettmer wrote...
> > Hat jemand praktische Erfahrungen in grösseren Projekten? Im
> > Kernel läufts ja wohl gut, sonst hätten sie es anders gemacht :)
> 
> Der Kernel ist nicht wirklich ein großes Projekt, sondern vor allem
> ein weit verteiltes. Dafür wurde git entwickelt, und das merkt man
> dieser Suite auch weiterhin an (im Guten wie im Schlechten).

Jaaaaaaaa, das klingt schon wieder so, als ob Git nix für ne
Firma wäre... Oder ist das ein Spezialfall, der einfach mit
abfällt?

> > Migriert heute eigentlich noch jemand zu SVN oder nimmt man
> > gleich Git? Oder mercurial oder Bazar? Darcs eher gar nicht?
> 
> Die Wahl eines VCS ist sehr starke Sache der persönlichen Präferenzen
> (man darf auch "Glauben sagen) und ist ein Thema für ausgiebige
> Kriege, wenn man sich endlich auf den besten Editor (natürlich
> mcedit) geeinigt hat. Ich persönlich zum Beispiel mißtraue großen
> Programmen, die auf Skriptsprachen aufbauen (also bzr und hg).

:-)
Ich persönlich mißtraue Programmen, die nichtmal kompatibel zu
sich selbst sind (hg).
Mein Workstation hat SuSE 7.0, da kann ich mit CVS auschecken,
was ich mit SuSE 10.2 inner compile farm eingecheckt hab :)
(gut, mergen würde ich auf 7.0 auch nicht :))

> Ihr kommt von CVS? 

Kommen? Klingt so dynamisch. Würde eher sagen, wir stehen auf
CVS...

> svn ist in einigen Dingen doch schon erheblich
> fortschrittlicher, 

Ja, ich weiss, es kann HTTP. Aber ich find ssh eh besser :-)
Was kann svn, was cvs nicht kann? In tags einchecken, gut, ist
ein Nachteil. Geänderte Sandboxes nicht taggen? Nachteil. Globale
Repo-Nummer? Nett, aber der Preis, dass damit keine Submodule
gehen, ist zu hoch.

Kann das eigentlich git? Mit CVS checken wir paar Verzeichnisse
einfach in andere Namen aus, weil sich mal was geänderte hatte.
SVN kann das wohl immer noch nicht, obwohl man wohl an
tree-conflicts arbeitet.

Ach, bei CVS hab ich öfter mal ,v Files kopiert und mit'm Editor
die Tags rausgelöscht. Geht auch. Wüsste bei SVN nicht, wie man
das machen würde.

Du kennst CVS, SVN und Git? cool dann muss ich weiter nerven :-)

Wir haben sogenannte Systeme. Das sind ganz kleine CVS module, da
steht im Wesentlichen eine Liste der zu verwendenen CVS-Module
drin (Repo, Modulname, Modulverzeichis, Branch, Zielverzeichnis)
und Administratives. Dann gibts ein Skript das die Sourcen holt.
Das Tolle ist: man kann dann dort oder in irgendeinem
Unterverzeichnis ganz normal CVS benutzen. Es funktioniert
einfach. Man merkt von den Repo-Grenzen nichts. Toll!
Für SVN wurden von einem Kollegen mal diverse Skripte angefangen,
die das emulieren, aber so richtig toll war das alles nicht.

Wie macht man das mit git?

> und wohl auch relativ schnell zu lernen, aber für
> mich hat es zu sehr etwas von "altbacken". Es klingt albern, aber die
> Geschwindigkeit von git im Status-Kommando macht einiges aus, auch
> wenn es vielleicht nur 0,1 Sekunden statt 0,5 sind.

Ich finde, eines der tollsten Sachen ist, dass git nach einem 
git checkout -b my_new_scm_config
git pull feature1 feature2 feature3
dann nach checkin und push und pull etc. am Ende auch das letzte
Repo noch weiss, dass das entstandene eben von feature 1-3
abhängt.

Für mich das dieses Wissen der Mehrwert!

Was damit alles geht. Fetzt.

> > Allerdings braucht man auch Konventionen, beispielsweise wie ein
> > (oder mehrere) Austausch-Repos zu verwenden sind. Im Git Handbuch
> > ist ein Diagramm mit zwei Partnern. Dort hat jeder ein public
> > repo. Kann man da nicht auch einfach ein gemeinsames public repo
> > nehmen?
>
> git läßt hier viele Freiheiten und zwingt damit die Nutzer, sich selber
> was auszudenken.

Ja, gut gesagt, genau!
Damit steht und fällt natürlich ne Menge. Vergleiche kann man
IMHO auch nur machen, wenn man geeigente Konventionen hat.

> Das übliche Verfahren ist verteilte Repositories und
> integration manager, einen Ansatz mit zentralem Repository und
> commit access für alle kann man immer noch fahren. Ich habe an
> der Stelle mehr als einmal überlegt, in der Konstellation
> "kleine Firma, kleiner Entwicklerkreis, der sich vertraut" mit
> einem svn repo zu arbeiten und die Entwickler wählen zu lassen,
> welchen Client sie verwenden 

Warum sollte man den Entwicklern einen Clienten vorschreiben?
Ich glaub, bei uns nehmen alle fast nur Kommandozeilen CVS, weil
die GUIs alle immer irgendwelche Probleme haben (sei es, dass
Unterverzeichnisse verschiedene Branches oder verschiedene Repos
sind). Bei SVN ist das weniger schlimm, aber SVN kann sowas ja
auch überhaupt nicht. Ich vermute, die CVS GUIs funktionieren
dann auch, wenn man sowas nicht macht.

> - da mir aber der git-svn-Konnektor noch jedes Mal einen Haufen
> Trümmer erzeugt hat, wenn ich damit rumprobiert habe, ist das
> allerdings nie geworden.

Ohh, was erzeugt da Trümmer? Ich wollte mal mit git-cvs
rumspielen, ist dann wohl keine gute Idee?

> Die git-Verfechter vertreten recht lautstark die Meinung, daß das
> von CVS und svn bekannte Konzept der Zentralisierung böse(tm) ist. 

Ja, da mögen sie in ihrer Umgebung bestimmt Recht haben. Meine
Umgebung ist eher zentral (nicht so ganz, aber ziemlich :)). Das
kann man gut oder schlecht finden. Das kann man beim Wetter auch.
Aber es findet trozdem statt :)

> Ich vermag, gerade im obigen Szenario durchaus Vorteile darin
> zu sehen. Es gibt jederzeit einen klar definierten Stand, und
> alle haben darauf Zugriff. "integration manager" klingt nach
> einem Job mit viel Spaß (Streß von allen Seiten), der ab einer
> gewissen Größe unvermeidbar wird, aber bislang ging's bei mir
> auch ohne.

Ja, viel Spaß, aber man kann es so oder so gestalten...
Bei uns werden die haarigen Sachen (insbesondere merges)
delegiert - die haben dann erstmal Spaß (50KLOC diff merge mit
Konflikten in 100 Files und make check läuft auch danach nicht
durch) :-)
Aber zentral kann man das lösen. Die haben dann Priorität und
holen sich den Entwickler an den Schreibtisch oder ans Telefon,
wenn was unklar ist.

> > Dann hab ich meist ne CVS Sandbox pro Branch. Klar, weil das mit
> > CVS sonst nicht so gut geht (aber ich nutze auch gemixte
> > Sandboxes). Bei SVN weiss ich das nicht, hatte da immer nur in
> > jeweils einem Branch zu tun.  Bei Git braucht man das nicht -
> > lieber möchte man nur eine Sandbox und die dann umschalten (also
> > checkout <otherbranch>).
> 
> Mit Verlaub, das habe ich nicht verstanden, aber es klingt ziemlich
> kra^Wanstrengend. Mit git hat sich auch mein Stil massiv verändert,
> da mache ich branches häufiger als in svn commits. Und es lohnt sich.

Sorry, war wohl zu konfus, was ich schrieb.
Wir haben Projekte, die holen sich sagen wir mal 40 libs als
SCM Komponenten (dazu werden verschiedene CVS Module aus
verschiedenen Repos zusammengesammelt). Jede hat ihr configure
und ein projekt-globales top-configure (das die anderen als
SUBDIRS hat). Im configure steht ne Versionsnummer (das ist
gleich wichtig).
Diese SCM Komponenten Kombination heisst `SCM configuration'. Die
zeichnet ein Projekt (also ne Applikation oder was auch immer am
Ende hinten rausfällt) aus. Die sind zum Teil 8 Jahre alt und die
SCM Komponenten noch älter. Gibt meist ne Menge (alter) Branches.
Teils sind die 5 Jahre auseinander und im Prinzip verschiedene
Software. Produktlinien.
Wenn man jetzt ne Version (Linie) 1.0 hat (mit Fixes für 1.0.1
usw), würde ich mir ein myapp-branch-1_0 (für die Namen haben wir
Konventionen) auschecken. So auch myapp-branch-1_2 und
myapp-branch-2_0. Darunter gibts dann die 40 Unterverzeichnisse
mit den 40 SCMs mit den 40 configures.
Die Versionen von 1.0.x und 1.2.x sind natürlich essentiell
anders, damit sind die configures anders, damit sind die
config.h's unterschiedlich.

Manchmal hole ich mir in einem Unter-Unterverzeichnis, also
myapp-branch-1_0/lib1/module1 oder so, mal einen anderen Branch
(also genau dort unten ein 1.0.2). Im Detail ist das alles
komplizierter, weil die lib1 in myapp1.0 ja keine 1.0 sondern
vielleicht eine 2.4 ist (lib1 kann ja älter sein). Aber egal.
Jedenfalls kann ich da z.B. mal eben Sourcen aus einem anderen
Branch probieren. Oft geht das dann nicht, weil die 5 Jahre
neuere lib1 version 3.0 von baselib version 6 abhängt, in myapp
1.0 aber nur ne version 3 drin ist. Aber egal :)
Wenn es denn geht, kompiliert make einfach die sourcen da neu,
linkt alles durch und fertig. Dauert bloss 2 Minuten.

Wenn ich jetzt einen Branch wechseln würde, würde sich die
config.h ändern. Da alles irgendwie ne config.h includen muss,
wird make also /alles/ neu kompilieren. Das dauert. Wechsel ich
zurück, neue config.h, also /alles/ neu kompilieren.
Mit verschiedenen sandboxes ändern sich die config.h's aber eben
nicht, also muss ich nur die (in dem jeweiligen Branch)
geänderten Files neu kompilieren.

In der Praxis muss man dann oft ein Feature für 1.x und 3.x,
wünschenswert 2.x, implementieren. Da braucht man dann sowas.

Na, ich weiss nicht, aber viel besser ist die Erklärung wieder
nicht geworden. Sorry. Ist halt alles gar nicht so trivial.

Jedenfalls würde ich da mit Git wegen config.h auch weiterhin
verschiedene Verzeichnisse benötigen, wenn ich sauber arbeiten
will.

Rails hat dieses Problem z.B. nicht, weil man keine config.h hat.
Da reicht dann auch eine Sandbox.

> git aktualisiert im Zweifelsfall die mtime, denn das ist ja gerade
> eine Anwendung: Springt man in einen anderen branch, soll bitte eine
> Neuübersetzung erzwungen werden.

...was dann schnell mal 30 Minuten dauert - also mehrere
Sandboxes, ja?

> > Tja, und noch ein Detail. Ich CVS-Files haben wir immer schön
> > "$Name: $".
> 
> Das fehlt aus einem guten Grund. Ich müßte es raussuchen, in meiner
> Erinnerung war es "Bläht die commits auf". Mit hooks könnte man sich
> das nachbauen, aber ich habe keine Erfahrung damit.
> 
> > Das hat einen wichtigen Grund. (...)
> 
> Vielleicht kannst Du das mit "git blame" erledigen?

Nein, ich kriege ja eine Datei per Mail. Ich weiss nicht, wo die
mal herstammte. Vermutlich aus irgendeiner source dist, ok, aber
aus welcher? Welcher Branch? Manchmal würde ja schon das Jahr
helfen ;) Bei einer Datei kriegt man es auch mit CVS noch hin,
wenn man denn das file kennt (also die Änderungen). Paar
checkouts, vor, zurück, zack, da isse. Aber oft versagt das eben.
Mit $Name$ kein Problem. Per Konvention muss bei uns alles aus'm
getaggten CVS export gebaut werden, also steht da ein Tag drin.
Zentrales Repo, also klar woher auschecken. Da gibts ein Skript.
Das kriegt dann den CVS Tagnamen (aus $Name$) und es holt die
richtigen Sourcen (kann die auch gleich bauen, wenn man will).

>     Christoph, sollte längst im Bett sein

ey, echt, da sagste was ... :)
Danke für die ganzen Infos.

Überhaupt an die ganze Liste. Danke für die ganzen Infos. Bleibt
spannend :)

oki,

Steffen

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