[linux-l] Nutzt jemand Git?

[Steffen Dettmer]

Hi,

erstmal danke für die vielen Antworten :)

* Volker Grabsch wrote on Tue, May 05, 2009 at 00:47 +0200:
> Steffen Dettmer <steffen at dett.de> schrieb:
> > Praktisch interessiert mich aber, ob Git in der Praxis auch für
> > `nicht-Freaks' nutzbar ist (z.B. für outsourced development).
> 
> Grundsätzlich ja. Aber nur, wenn die Entwickler willig sind,
> umzulernen. Es ist nebensächlich, ob es Bazar, Git, Mercurial
> oder Darcs ist. Viel wichtiger ist, dass die Entwickler von
> dem Ding schon Gutes gehört haben, bzw. davon begeistert sind
> ("... wollte ich schon immer mal ausprobieren.")

(Wenn das so stimmt, müssten wir also bei CVS bleiben, bis wir SVN
`aufgedrückt' bekommen...)

> > 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.
> 
> Dem kann ich nur zustimmen, und wenn deine Kollegen der gleichen
> Meinung sind, spricht nichts gegen einen Umstieg auf ein DVCS.

Na ja, klar, wenn alle dieser Meinung sind, würde man es einfach
mal ausprobieren und gut. Das wäre ja einfach. Ist es aber nicht ;)

Dazu schreibe ich später noch mal was.

> > 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?
> 
> Auf diese Frage gibt es zwei Standard-Antworten:
> 
> 1. Ein zentrales Repository, in das jeder etwas hochladen kann,
>    ist meistens keine gute Idee. Es ist ein Symptom eines Planungs-
>    Fehlers, der dadurch zustande kommt, dass sich der Planer an die
>    Einschränkungen von CVS/SVN zu sehr gewöhnt hat.

Ja, das habe ich so auch schon gelesen. Ich verstehe es aber
in diesem Zusammenhang nicht. Wenn man ein GPL Projekt
entwickelt, macht das Sinn. Irgendwo las ich `man muss nicht
darüber reden, wer drin und wer draussen ist'. Aber in einem
klasischen kommerziellen Umfeld macht das wenig Sinn. Die meisten
Unternehmen etc. sind ja hierachisch (zentral) aufgebaut.

> 2. Wenn es wider Erwarten gute Gründe dafür geben sollte, nimm
>    besser _nicht Git_ dafür. Das Verhalten von "git push" ist
>    m.E.n. hochgradig kontra-intuitiv. Nimm stattdessen Mercurial
>    oder Darcs, denn "hg push" bzw. "darcs push" tun genau das,
>    was man erwartet.
> 
> Anders gesagt: Ich habe den Eindruck, dass Git vorrangig für
> Nur-Pull-Szenarien ausgelegt ist. Push-Szenarien machen mit Git
> keinen Spaß, aber die hat man auch praktisch nie.

Ahh, das ist ja interessant! Hier muss ich wohl noch ne Menge
nachlesen und verstehen lernen.

> > Ich hätte also gern mindestes für Backups eine Art `zentrales
> > Repo'.
> 
> Wenn das der einzige Grund ist, trifft Punkt 1. (siehe oben) zu.
> 
> Wenn du ein großes Repository mit allen Branches und Changesets
> hast, weiß dieses Repository immer noch nicht, welcher Entwickler
> welche Teilmenge der Changeset gerade in seinem Arbeits-Repository
> hat. Es wäre daher unverantwortlich, nur dieses große Repository
> zu sichern. Ich persönlich denke, dass in jedem Fall sämtliche
> Entwickler-Rechner gesichert werden sollten.

Wir haben ein paar hundert GB auf compile servern. Die haben da
z.B. ein RAID0 über 4 Platten, paar CPUs und 8 GB RAM oder sowas.
Da gibts keine sauteuren LTOs und Leute, die die Bänder wechseln.
Das sind (meistens) C compiler build dirs. Warum soll ich die
ganzen .o's sichern?!
Ein zentrales Repo zu sichern ist doch ungleich eleganter.
Automatisch wird genau das gesichert, was wichtig ist, es stört
keinen, es merkt keiner, es macht alle irgendein (natürlich
zentrales) Heinzelmänchen.
Unsere ganzen Repos zusammen jedoch sind bloss ein paar GB. Da
sichert man auch automatisch sozusagen differentiell (weil das
CVS ja nur die Änderungen speichert) und kaum Redundant.

Bei GPL-Projekten sehe ich, warum man das dezentral möchte. Aber
hier?
Ein Entwickler soll gar nicht irgendwelche privaten Teilmengen
haben. Was ist denn, wenn er krank wird?
Wir müssten sowieso die ganzen Branches verteilen. Praktisch ist
es bei uns so, dass ein Entwickler sein Feature in den wichtigen
Produktlinien (aktuell CVS Branches) testet. Dazu muss er die
natürlich haben (also z.B. vom Integrator pullen).

Ich persönlich denke, dass Entwickler-Rechner gut sind, wenn man
sie nicht sichern muss! Da soll nix drauf sein. Das soll ein
Stangending, automatisch per Skript installiert, sein. Bei
Ausfall Hardwarewechsel, initial Image zurücksichern, fertig.
Alles an Daten sollte IMHO auf Servern sein (die gesichert
werden, RAID haben mit Reserveplatten im Schrank etc).

> > Das `zentrale Repo' aus build-Sicht (wenn man CVS:GIT wie
> > 1:1 mappt :)) wäre IMHO das Arbeitsreprository des Integrators.
> 
> Wenn ihr einen Integrator habt, sollte dieser regelmäßig
> aus allen anderen Repositories "pull"en. Ich halte es für
> keine gute Idee, dass die Entwickler ungefragt ins Repository
> des Integrators ihr Zeug hinein-"push"en können. Das mag bei
> CVS und SVN üblich sein, aber nur, weil's dort nicht anders
> geht.

Ja, hier gibts noch einen indirekten Vorteil von CVS (oder SVN):
`vergessene' Änderungen werden (meist - natürlich je nach
Strategie) automatisch mitgemergt. Das kann gut oder schlecht
sein. Meistens wohl beides.

> > Gut, bei einem 10 KLOC project ist's egal,
> > aber da reicht auch CVS oder gar ein SVN,
> 
> Kurze Anmerkung, auch wenn's nichts mit der eigentlichen
> Frage zu tun hat:
> 
> _Gerade_ bei kleinen Projekten sollte man auf CVS oder SVN
> verzichten!
> 
> Grund #1: Wenn man sich eh in DVCS einarbeiten möchte, ist so
> ein kleines Projekt die ideale Gelegenheit.

Das muss so nicht richtig sein. Bei uns wäre die Hürde recht
hoch, weil man viel Vorarbeit machen müsste. Das geht ja schon
mit den Entwicklerrichtlinien (coding rules) los, über Backup hin
zu Reproduzierbarkeit jedes Releases aus Sourcen von Backups.

> Grund #2: Bei CVS und SVN brauchst du immer noch irgendwo ein
> zentrales Repository, was höheren Admin-Aufwand bedeutet, und
> es kettet all deine Mini-Projekte an ein zentrales Repository.
> Sowas hab ich früher gemacht, und es ist nervend. Ich bin dann
> dazu übergegangen, jedem Projekt ein eigenes SVN-Repsitory direkt
> im Projekt-Ordner anzulegen, sodass alles, was zum Mini-Projekt
> dazu gehört, an einer Stelle ist. Bei einem DVCS brauchst den
> Quatsch nicht. Ein "hg init" oder "darcs init" genügt, und schon
> ist das Repository (= Arbeitsverzeichnis) sofort einsatzbereit!

Auch das muss so nicht richtig sein. Wir haben eine kleine
Umgebung die mittels diversen Perl- und Shellskripten eine
Umgebung erzeugt (auschecken aus den verschiedenen CVS Quellen,
autoconf und Freunde, Sourcecode Generierung, etc).

Welchen Admin-Aufwand meinst Du?
Weiß jetzt nicht, was ein Mini-Projekt ist, aber gerade da muss
man es doch so ablegen, dass man es in 3 Jahren noch
wiederfindet. Da braucht man ja eh einen zentralen Index und
Projekte sind eh zentral und haben eine Kostenstellennummer.
Klar, bei internetbasierter Opensource-Entwicklung in wechselnden
Teams, die sich vielleicht kaum kennen, ist das alles anders.

> > Tja, und noch ein Detail. Ich CVS-Files haben wir immer schön
> > "$Name: $". Das hat einen wichtigen Grund. Wenn nämlich jemand
> > ein CVS Export File ändert und uns zurückschickt, weiß er nicht,
> > wo er das mal herhatte.
> 
> Sowohl SVN als auch die DVCS haben ebenfalls solch eine Möglich-
> keit, da musst du einfach in der Doku nachschlagen. Allerdings
> machen sie es alle auf unterschiedliche Art und Weise. In SVN
> ist es ein Property, in Mercurial ein Postprocessing-Script, etc.

Aber das geht doch logisch überhaupt nicht. Man muss doch genau
das eine unter den unendlich vielen Source-Repos erkennen, weil
doch alle anders sind; Branchnamen und Tags sind auch nur lokal.
Wie identifiziert man denn Sourcen? Ich will zu einem Binärfile
(build) über ein Symbol sämtliche Sourcen holen können (und mit
debugsymbolen bauen, um Fehler analysieren zu können).
Da kann es doch keinen einfachen Mechanismus geben, da braucht
man ja noch mindestens eine Konvention dazu (z.B. ein Bau-Repo
oder sowas). Was macht man da in der Praxis?

oki,

Steffen

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