[SAGE-MUC] DVCS für System-Administration?

[Olaf Radicke]

Am Sonntag 06 Juni 2010, 08:07:55 schrieb Marko Lorentz:
> Das ist so nicht ganz richtig. svn ist ein "medium scale"
> Version-Management. Es hat im professionellen Bereich - wo Projekte über
> Jahre laufen und evtl. hunderte von Mitarbeitern partizipieren - nur wenig
> Verbreitung. Insbesondere die fehlenden Features für vernünftiges Merge
> und Variantenmanagement (neudeutsch: software product lines) lassen es
> hier oft ungeeignet erscheinen. Die angesprochene Ablösung von svn + cvs
> durch verteilte Systeme findet also in erster Linie bei kleinen bis
> mittleren Projekten und im nicht-professionellen Bereich statt. Ausnahmen
> bestätigen wie immer die Regel.

Wirft natürlich gleich die Frage nach: "Was ist ein professionellen Bereich?" 
auf. Gerade vernünftiges Merge punktet Git & Co. Bei SVN (sf.net) habe ich es 
schon oft erlebt, das ein Entwickler mal eben die Commits von einem Andern 
rückgängig gemacht hat, weil er kein Bock hatte die Konflikte auf zu lösen, 
die seine Änderungen ausgelöst haben. Auf die Art und weise, kann man 
wunderbar, den Schwarzen Peter immer weiter Reichen. Irgend wer wird sich 
schon erbarmen und die Konflikte auflösen. Wenn irgend ein Entwickler ein 
Saustall im SVN zurück lässt, der sich nicht kompilieren lässt, haben ihn beim 
nächsten update nach und nach alle Programmiere in ihren Sandboxes. Wenn man 
produktiv weiter arbeite will, ist man also quasi gezwungen, den Saustall von 
Anderen auf zu Räumen.

Ganz anders bei Git & Co. Ich pull die Änderungen wann ich will. Wenn es 
Konflikte gibt, ist der Verursache so lange Außen vor bei der Entwicklung, 
biss er den Konflikt selber aufgelöst hat. Wenn er sich mal alleine nicht mehr 
aus dem Schlamassel befreien kann, dann kann er freundlich fragen, ob ein 
Anderer sein Chaos pullt und für ihn auflöst. Aber niemals sind alle Anderen 
lahm gelegt, weil irgend wer Freitag Nachmittag 10 Min. vor Feierabend Schrott 
commitet hat.

> Die Antwort auf die neuerdings so oft gestellte Frage, ob ein
> zentralisiertes oder ein dezentralisiertes Versionsmanagement besser ist,
> basiert IMHO weitgehend auf dem verwendeten Entwicklungsprozess, jedoch
> nicht auf den Features der Systeme, denn diese sind bei z.B. bei svn und
> .hg weitgehend gleich. 

Trifft für Git nicht zu. Das gibt es Dinge, da träumt man als SVN-Benutzer nur 
von...

> Wenn der Prozess stark entkoppeltes Arbeiten
> erlaubt oder sogar favorisiert, dann ist die Entscheidung für git & Co.
> naheliegend. Bewegen wir uns aber in einer Welt mit starker Kopplung an
> automatisierte Integrations- oder Systemtests (die auch schon mal eine
> ganze Nacht lang laufen), dann ist ein zentrales Einchecken in ein
> continuous integration basiertes System sinnvoller

Man kann auch mit Git ein zentrales System in das gepusht wird einrichten. 

> - allein schon aus
> Gründen der QS.

Gerade QS spricht für Git & Co, weil man damit ein Mehr-Augen-Prinzip 
verwirklichen kann. Die Rechteverwaltung mit SVN ist sehr beschränkt. Man kann 
nicht explizit sagen User darf nur in bestimmte Zeige ein- oder auschecken. 
Zweige anlegen oder löschen. Tags setzen oder löschen usw. usw...

Gruß

Olaf

-- 
Meine Rechtschreibfehler stehen unter der Creative Commons Lizenz.
(Bearbeitungen und Weitergabe unter gleichen Bedingungen):
http://creativecommons.org/licenses/by-sa/3.0/de/