[Allegro] Argumente fuer git

[Anando Eger]

Hallo Herr Berger,

danke für den wirklich guten Grundlagenbeitrag!
Sie schrieben zu verteilten VCS: 

> Hier ist also zunaechst einmal ein "Pull"-Konzept grundlegend
> gewesen, Pro Repository hat eigentlich nur eine Person Schreibrecht,

Für Allegro scheinen mir eine Reihe relativ unabhängiger 
Repositories sinnvoll - z.B. 
- Kern-Klassenbibliothek
- avanti
- acon/a99
- Parametersatz A
- Parametersatz N

Die könnten theoretisch auch unter verschiedenen VCS 
organisiert werden ... ein einheitliches ist natürlich
besser.

Viele Grüße
Anando Eger



On 21 Aug 2010 at 16:26, Thomas Berger wrote:

> -----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-----
>