[linux-l] Nutzt jemand Git?

[Steffen Dettmer]

Hi,

danke auch für die ganzen Infos!

* Marian Rudzynski wrote on Tue, May 05, 2009 at 01:11 +0200:
> > Hat jemand praktische Erfahrungen in grösseren Projekten? Im
> > Kernel läufts ja wohl gut, sonst hätten sie es anders gemacht :)
> >
> Wurde sogar extra fuer den Kernel entwickelt.

(ja eben :))

> > Migriert heute eigentlich noch jemand zu SVN oder nimmt man
> > gleich Git? Oder mercurial oder Bazar? Darcs eher gar nicht?
> >
> >
> Das kommt auf dein Projekt und deine Arbeitsweise an. Ich tendiere
> immernoch eher zu Subversion einfach weil ich nur Projekte habe die
> wenige (<100.000) Files umfassen und ich zentralisierte Repositories
> lieber mag - allein schon um alleinige Zugriffskontrolle zu haben.

Was heißt dass, dass man bei Projekten mit mehr als 100k files
lieber kein SVN nehmen sollte? (weil? Link zur Hand?)

> Git ist ideal fuer dezentralisierte Entwicklerteams von grossen 
> Projekten (viele, nicht grosse Files ..fuer grosse Files dann doch 
> lieber Subversion)

Was ist groß? Wir haben typischerweise Sourcen (<< 1 MB) aber
auch paar Dokumente (<< 1 GB). Muss natürlich beides gehen.

Wir haben eher zentrale Entwicklerteams bzw. auf wenige Standorte
verteilte.

Ich glaub, eines unserer Kernprobleme/Themen ist, dass wir viele
komplexe Branches haben, zwischen denen hin- und hergemergt
werden muss. Die Software wird jahrelang gepflegt (da hat sich
Java in der Zeit schon dreimal geändert :)). Merges sind schon
mal 50 oder 100KLOC gross und dauern drei Tage.

Das zentral dezentral etc ist mir weniger wichtig als guten
Support dafür. Bei SVN war ich sehr enttäuscht. Früher sollte man
sogar mal über die Repo-Revision-Nummer mergen. Ein Merge ist
dann aber auch eher ein check-in.

Das ist bei Git (HG, ...) viel viel besser.

> > Überhaupt, wenn man Git (oder hg) haben kann, warum würde man SVN
> > nehmen?  Ich habe danach gegoogelt, aber meist pro-Git-Artikel
> > gefunden, die wohl weniger objektiv sind. Anscheinend verwenden
> > ja sehr viele SVN. Bei uns in der Firma will man uns am liebsten
> > nach SVN migrieren. mmm... Heute noch zu SVN? Für mich wirkt SVN
> > eher wie ein CVS mit ein paar Bugfixes (und paar weniger
> > Features, die die meisten aber nicht brauchen).
> >
> Siebe oben. Und der grosse Bulk an Pro-Git-Artikeln die so
> auftauchen sind von Ruby on Rails Evangelisten die einfach
> generell begeistert von jeder neuen Technologie sind und sie so
> lange zweckentfremden bis der naechste leuchtende Hype daher
> kommt.

:-)

Ist denn Git nur ein leuchtender Hype? Ist mercurial besser oder
ist das nur Geschmackssache? Bei der vielen Religion im VCS
Bereich ist man ja schnell irritiert...

Als ich damals RCS kennenlernte, fand ich das Klasse. CVS ist die
natürliche nächste Evolutionsstufe, fand ich (SVN ist ca. das
gleiche. Neuimplementiert, viel weniger Bugs, was wirklich ein
Riesenvorteil ist, paar neue Features. Paar alte gehen nicht,
aber die meisten brauchen die nicht [wir schon]).

Ist DVCS nicht die nächste Evolutionsstufe? RCS->CVS->Git?

Bei google gabs ja so einen Artikel Git vs. HG. Der Autor fand HG
besser, aber viele Kommentare kritisierten das (recht
überzeugend, wie ich fand).


> Subversion wird ausserdem weitgehend als der Nachfolger von CVS
> angesehen und macht imho CVS gaenzlich ueberfluessig.

Ja, wenn man jetzt in einer Java-Welt lebt und ständig von null
anfangen kann, mag das sein, aber wenn man viele teils 10 Jahre
alte CVS Repositories hat, viele Dokumente, Prozesse, Skripte
usw., die darauf aufbauen, dann ist das eben nicht so. Und bloss
weil SVN jetzt HTTP kann... Na, lassen wir das. Ich mag halt CVS
und finde SVN ziemlich genau gleichmächtig (damit lohnt die
Migration nicht, kostet Mannmonate und bringt nix, ausser, dass
es teils noch langsamer wird und mergen wohl noch
unübersichtlicher, aber egal und am Thema vorbei :)).

Ganz wichtig ist ja auch, wie die Qualifikationen sind. Wir haben
ein paar Leute, die seit 10 Jahren mit CVS arbeiten. Man kennt
die meisten Bugs und kommt irgendwie klar. SVN kenn ich bei uns
nur in Projekten, die nicht sooo komplex sind (also keine 20
Branches in denen hin- und hergemergt werden muss).

> > Praktisch interessiert mich aber, ob Git in der Praxis auch für
> > `nicht-Freaks' nutzbar ist (z.B. für outsourced development). Ich
> > persönlich fand (nach Doku, praktische Erfahrungen habe ich ja
> > nicht) es eigentlich einfach. Klar, man muss sich darauf
> > einlassen, aber dann gibt es viele Features, die ich mir bei CVS
> > und SVN (was ich kaum nutze) schon immer gewünscht habe.
> >
> Git ist sehr viel komplizierter zu verwenden als Subversion.
> Deshalb findest du auch millionen von "hier ist meine .profile
> mit 40 git aliasen"-Blogposts fuer den unwissenden Mac User,
> der gerne jede Zeile die er eingeben soll komplett
> vorgekaut vorfindet.

Das wäre für uns akzeptabel, denke ich. Wir müssten eh
Entwicklerrichtlinien, Trainingsdoku entwickeln und schreiben und
so weiter. Alles gar nicht so einfach. In der Praxis gibt es (je
Thema unterschieliche) Leads, deren Ideen (Skripte, Configs, ...)
von anderen (angepaßt) übernommen werden. Das ergibt sich dann
jeweils (man sieht was bei einem Kollegen und kopiert es).
Die meisten nutzen nur sehr kleine Teile. Große Merges machen
meist nur zwei, drei Leute.

Einmaliger .profile-Aufwand würde bei einer Migration eingeplant
und wäre sicherlich vertretbar.

> Aber mit wenigen Handgriffen kannst du Git vor allem ohne
> zentralen Server verwenden, was es sehr viel
> "Einsteigerfreundlicher" macht.

Ja, das ist nett. Geht das mit SVN nicht? Mit CVS gehts. Aber
nutzen wir nie. Neues Modul zu erzeugen ist auch gar nicht so
einfach, das machen auch nur wenige (nicht wegen CVS, sondern
autoconf und vielen anderen Skriptereien).

> Wenn du Git einfach mal ausprobieren moechtest kannst du dir einen
> Account auf Github.com erstellen und ein beliebiges Projekt forken um
> damit rum zu spielen.

Auch ne Idee, genau. Ich benutze Git im Moment bloss für ne kleie
Rails-Spielerei. Muss erstmal die Basics lernen. Ist ohne Zeit
nicht so einfach ;)

> Ein Backup machst du also mit tar -cjf working_dir.tar.bz2 working_dir ;)

Das ist doch aber inakzeptabel!

Es kann nicht überwacht oder getestet werden. Es ist nicht
automatisch und man kann es nicht an ein "Heinzelmänchen"
übergeben. Backup muss eine Basisfunktion der IT Infrastruktur
sein. Es muss einfach zuverlässig funktionieren, ohne das ein
Entwickler überhaupt davon weiß. Wenn was kaputt geht, wird es
getauscht. Der Entwickler geht inzwischen einen Kaffee trinken
oder arbeitet woanders weiter, bis die Störung behoben ist (z.B.
Hardwaretausch).

Backup ist IMHO sowieso recht zentral, weil irgendjemand muss die
vertraulichen Bänder ja ins feuerfeste Bankschließfach bringen
(oder was auch immer man da nu genau macht). Kann ja nicht jeder
Entwickler dafür zuständig sein sollen.

Akzeptabel wäre noch sowas wie:
  Alles wichtige wird von jemand gepullt und damit gibts ein Backup.
Das klänge wieder so nach Evolution und DVCS sind automatisch
einfach nur geil, aber leider funktioniert es nicht
(beispielsweise könnten zufällig alle Kopien auf einer Platte
sein, die Infrastruktur kann davon ggf. sogar abstrahieren, so
dass man es nichtmal sieht).

> Ich verwende Git bisher auch nur fuer Ruby on Rails Kram, aber
> du kannst davon ausgehen dass wenn es fuer den kernel verwendet
> wird, die timestamps korrekt sitzen. Erfahrungswerte habe ich
> da aber null.

Nimmt Kernel denn autoconf?
Wie unterschiedlich sind die Sachen zwischen den Branches?

Bei uns würde das wechseln eines Branches in jedem Fall zu neuen
configures führen (Versionsnummer in IC_INIT), damit neue
config.h (wir haben pro Projekt teils 40 configures in 40
Unterkomponenten) - und damit würde dann immer /alles/ neu
kompiliert.

Daher nehme ich an, man braucht einen Trick - oder doch wieder
eine Sandbox pro Branch... hum :)

oki,

Steffen

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