[Allegro] Argumente fuer git

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Am 21.08.2010 12:51, schrieb Klaus Lehmann:
> On Sat, 21 Aug 2010 12:22:52 +0200 Fischer, Thomas wrote:
> <>Hallo Herr Eger,
> <>
> <>soweit ich sehe, treffen die ersten vier Punkte auch auf Subversion
> zu (bei 4 lokale Version 'Working Copy' statt clone).
> 
> tach an alle, 
> ich bin dafür bei svn zu bleiben!
> himmel, was spricht dafür, unbedingt die pferde zu wechseln?

Ich finde eine Diskussion durchaus angebracht, bislang wird SVN
ja nicht wirklich fuer Versionsverwaltung genutzt, eher als eine
Art Archiv, wie man es mit einem reinen DAV-Laufwerk auch hat.

SVN (und die anderen Vertreter der *zentralen* Quellverwaltungssysteme)
setzen ein Entwicklungsparadigma zugrunde, wo letztendlich mehrere Personen
Schreibrecht in das zentrale Repositorium haben (wobei gerade SVN allerdings
noch differenzierte Rechtevergabe erlaubt). Das Modell ist also
"push", mehrere Personen sind in der Lage, ihre Aenderungen in das
Repository hineinzudruecken (natuerlich gibt es dort noch Konzepte
wie Tags und Branches, mit denen die Lebenszyklen typischer Software-
projekte abgebildet werden, d.h. nicht jede Aenderung betrifft unbedingt
sofort die eine und einzige "aktuell gueltige" Version des Produkts).
Personen ohne Schreibrecht koennen einer mit Schreibrecht einen Diff
per Mail schicken oder sonstwie zugaenglich machen, den diese dann
probeweise einarbeitet. Natuerlich geht auch eine "vollstaendige
verbesserte Version", die Person mit Schreibrecht muss sich dann
(unterstuetzt durch die Werkzeuge des Versionsverwaltungssystems)
selbst auf die Suche danach machen, was die Aenderungen sind und was
davon zu halten ist... Personen mit Schreibrecht muessen vor dem
"Committen" einer Aenderung ggfls. sich erst einmal mit dem aktuellen
Zustand des entsprechenden Teilbaums synchronisieren, d.h.
allfaellige Konflikte dadurch, dass andere denselben Teilbaum
geaendert haben, lokal aufarbeiten.

Git ist entstanden aus dem Beduerfnis, das Enwicklungsparadigma fuer
den Linux-Kernel aufrechtzuerhalten (nachdem Bitkeeper nicht mehr
"frei" war, musste ein Ersatz her). Hier ist es so, dass nur eine
Person schreiben darf und darauf angewiesen ist, ihm zur Kenntnis
gebrachte Aenderungsvorschlaege superschnell zu uebernehmen oder
abzulehnen. Soweit ich das verstanden habe wird das so organisiert,
dass mehrere Personen mit wiederum eigenen Repositories ihm zuarbeiten,
d.h. die wiederum nehmen von der Masse der Entwickler Aenderungs-
vorschlaege entgegen und setzen sich damit gruendlich auseinander.
Hier ist also zunaechst einmal ein "Pull"-Konzept grundlegend
gewesen, Pro Repository hat eigentlich nur eine Person Schreibrecht,
kann ihr Repository allerdings mit Versionen aus anderen Repositories
auffuellen. Das setzt voraus, dass die ebenfalls Online sind, oder
es wird irgendetwas per Mail oder sonstwie transportiert: Anders als
bei einem zentralisierten System ist das dann sofort in das eigene
Repository uebernommen (Versionen und Pfade geraten bei den verteilten
Strukturen nie miteinander in Konflikt), das Mergen mit etwas
Aktuellem steht allerdings immer noch an. Verteilte Quellverwaltung
mit nur einem Repository als Grenzfall verhaelt sich m.E. nicht viel
anders als zentralisierte Quellverwaltung, nur dass Konfliktsituationen,
wie sie durch Schreibrecht fuer mehrere Personen entstehen, u.U.
von der Software nicht so gut unterstuetzt werden.

Angeblich sind den verteilten Versionskontrollsystem die Merges
operationell nicht so teuer. Weil es nie "die" aktuelle Version
von irgendwas gibt, sind die Systeme m.W. auch besser darauf eingerichtet,
aktuelle Aenderungen, die sich auf vor sehr langer Zeit aktuell
gewesene Versionen beziehen, einzuarbeiten und in eine aktuelle
Version zu propagieren.

Die Diskussion der letzen Tage illustriert eigentlich recht gut das
Problem mit dem derzeitigen Entwicklungsmodell und zentralisierten
Repositories wie SVN: In Braunschweig gibt es ein zentrales Repository
(fuer Parameterdateien) in das nur eine Person schreiben darf (evtl.
auch mehrere Personen, *ich* allerdings nicht ;-) Als Entwickler
kann ich dieses Repository bei mir klonen und das dann dazu benutzen,
Diffs zu generieren, die ich an den Maintainer des zentralen Repositories
schicke. Solche Aenderungen werden aber traditionell nicht besonders
zeitnah eingearbeitet (etwa bis zum naechsten minor oder major Release),
und es gibt auch keine Branches (Maintenance der letzten Version plus
Enwicklungsbranches fuer die naechsten geplanten Versionen).
Umgekehrt - und das hat viel mit Allegro zu tun - benoetigt man haeufig parallel
diverse eigene Versionen von Parameterdateien, weil irgendwelche
Parameter einer speziellen Anwendung einen Eingriff in zentrale Parameter-
dateien erforderlich machen (#91 fuer die Anzeige auskommentieren und
solche Scherze). D.h. ich als Entwickler habe wiederum mein eigenes Versions-
kontrollsystem, in dem ich Fortschreibungen an zentralen Parameterdateien
fuer projektspezifische Klones und Abwandlungen davon propagiere (CVS
und SVN unterstuetzen so etwas partiell mittels sogenannter "Vendor
branches").
Finde ich nun etwas verbesserungswuerdiges, nutzt die Tatsache, dass ich
als Entwickler auch ein Versionskontrollsystem habe, eigentlich ueberhaupt
nichts, wenn es um die Kommunikation zurueck an das Original-Repository geht:
Bereits das Uebertragen "unveraenderter" Originaldateien aus dem
von mir geklonten Original-Repository in mein eigenes hat jegliche
Information zur Herkunft zerstoert (in den Versionskommentaren trage
ich allerdings die Versionsnummern des Herkunftsrepositories ein) und
ich kann dem zentralen Maintainer zwar einen Versionsunterschied in
meinem Repository zeigen, die resultierenden Patches helfen ihm aber
nicht. Damit die Aenderung im Originalrepository verarbeitbar ist, muss
ich sie in einer frischen lokalen Kopie des Originals (moeglichst auf
eine geeignete alte Version zurueckgedreht) noch einmal vornehmen, mit
diesen Diffs kann der Maintainer dann (theoretisch) etwas anfangen.

Ein verteiltes Versionskontrollsystem kann in dieser Situation Verbesserung
bringen, weil dem Maintainer Aenderungen effizienter zugaenglich gemacht
werden koennen. Das setzt natuerlich immer noch voraus, dass sowohl
Maintainer als auch die Zutraeger recht versiert im Umgang mit dem
Versionskontrollsystem sind und der Maintainer auch als Maintainer
handelt, d.h. recht zeitnah und umfassend agiert. Sonst stehen einfach
Zillionen von Patches im Repository herum und werden nie aktiviert...
Umgekehrt (insbesondere wenn man diverse "experimentelle" Branches als
"Spielwiese" fuer eine beschraenkte Anzahl von Entwicklern einrichtet,
sowohl kollektive als auch meinetwegen sogar "private", ist mehr Verantwortung
fuer den Code an die Entwickler delegiert (die muessen sich um Konflikte
kuemmern) und der Maintainer ist nur dafuer zustaendig, ab und an "fertiges"
aus dem "experimentellen" Branch in den "stabilen" zu uebertragen. D.h. fuer
ein Entwicklungsszenario, das man als "kooperativ" bezeichnen kann (Es gibt
Verabredungen, in gewisse Branches nicht hineinzuschreiben und die wenigen
Personen mit Schreibrecht halten sich daran; alle bemuehen sich, kleinschrittig
vorzugehen und nicht einmal im Jahr eine Pauschalaenderung abzuwerfen, die 37
Probleme zusammengefasst loest und dafuer 80% aller Codezeilen veraendert)
/kann/ eine zentralisierte Versionsverwaltung von Entwicklern wesentlich
beilaeufiger und weniger Maintainer-beanspruchend eingesetzt werden.
Mein Eindruck ist, dass verteilte Versionskontrollsysteme hocheffizient mit
der zusaetzlich benoetigten Buerokratie bei gewissen Kooperationsmodellen
umgehen, man darf das aber nicht mit Buerokratievermeidung verwechseln,
und absolut unsichtbar und ohne zusaetzliche Arbeit ist nur die
primitivste Variante von allen, das nackte DAV-Laufwerk nach dem Mau-Mau-
Prinzip: Was zuletzt auf den grossen Haufen geworfen wurde, das "gilt".

Attraktiv fuer den von mir im vorigen Absatz ausgeklammerten Bereich
der privaten Varianten koennte sein, in den Kontext eines privaten
"verteilten" Repositories (Mercurial) als Komponente ein zentralses
"zentralisiertes" Repository (SVN) einzusetzen: Also nicht als Import
von Momentaufnahmen des zentralen Repositories, sondern insbesondere
mit der Moeglichkeit von Recommits. Hier muss ich bei Gelegenheit
noch genauer nachlesen, wie das funktionieren kann.

Fazit: Es gibt Entwicklungszenarien, die verteilte Versionsverwaltungs-
systeme unumgaenglich machen und es gibt andere, fuer die solche Systeme
tendenziell Overkill sind. Schaun' mer mal.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAkxv4gIACgkQYhMlmJ6W47NOSQQAju46Z7D4mQUB0Gw84EiChDjM
pg0XSm0zzweyUCAO+ofuRoFMxwirSwNMeOR1be/w1NAKArNRNPzNKyl1zmfTZ+cH
GHQtf2yt8goQ6qqEgP1S/IfszBnM/Uz8NrLCDhb+krEBEXhCsrReEl66pcYmbRnQ
wCvDX1K7OMVWh/EJA80=
=U7QI
-----END PGP SIGNATURE-----