ALM-Prognosen #3: Verteilte Versionskontrollen halten Einzug in Unternehmen

Re: Fassen wir mal zusammen...

Avatar von Pickwick81

Pickwick81

mehr als 1000 Beiträge seit 12.07.2002

   E-Mail   
23.04.2012 22:24 Permalink
rammel schrieb am 23. April 2012 20:31

> Das wuerde ich nicht folgern. Man kann das VCS einfach unabhaengig
> vom vorhandensein von Schreibrechten nuzten, dass ist der Vorteil

Der Artikel impliziert aber einen geänderten Entwicklungsprozess, bei
dem man auf Rechteverwaltung in DVCS verzichten kann. Ohne das aber
genauer zu beschreiben. Hälst du das Szenario, dass ein Unternehmen
seine Repos irgendwem nur Read Only anbietet, der dann damit aber
produktiv und vollständig arbeiten soll, für praktisch relevant? Nur
dann haben DVCS einen Vorteil. Warum aber sollte ein Unternehmen
jemanden an einem geklonten Repo arbeiten lassen, den Master auf Read
Only, und dann nur irgendwann ein Diff zum Master mergen oder so?
Viel wahrscheinlicher ist es doch, dass das Unternehmen die komplette
Historie des gekonten Repo haben will, schon allein, weil es die
Entwicklung wahrscheinlich schlicht bezahlt hat. :-) Ich sehe nicht,
wie man das mit irgendeinem Patch von irgendeinem Benutzer irgendwo
auf der Welt an einem Open Source-Projekt vergleichen kann.

> Kann doch nicht, oder glaubst du, dass jeder Schreibrechte auf dem
> Linuxreleasebranch hat? 

Wie gesagt, ich habe den Artikel so verstanden, dass Rechteverwaltung
usw. komplett old school und mit DVCS unnötig ist. Der Linux-Kernel
scheint ja auch eher das gate keeper-Modell zu verfolgen, sprich es
dürfen nur bestimmte Benutzer im Master-Repo committen. Mit
Rechteverwaltung hat das nicht viel zu tun, wenn man sich die ACLs
beipsielsweise von Subversion anguckt. Ich bezweifle mal einfach,
dass bestimmte Tags im Master-Repo des Linux-Kernels beispielsweise
nicht nur für bestimmte Leute les-/schreibbar sind usw. Keine Ahnung,
ob Git das überhaupt bietet.

> Wieso sollte man das nicht auch in SVN verwenden? Kann man ohne das
> in einem Projekt >2 MA ueberhaupt sinnvoll arbeiten?

Bei Subversion und anderen zentralen VCS lese ich immer nur, dass man
gerade mit steigender Mitarbeiterzahl nicht mehr branchen und mergen
möchte, wiel es ja ach so schlecht handhabbar ist. Die erfahrungen
kann ich aber nicht bestätigen und ich arbeite schon ziemlich
ineffizient und hole mir immer alle Tags und Branches eines Repo. Der
Artikel bläst ja in ein ähnliches Horn und meint, Branches etc,. sind
nur im Zusammenspiel mit DVCS wirklich sinnvoll.

> Es gibt aber Task- oder Featurebranches, welche jeder ziehen kann.
> Aber die liegen selbstverstaendlich auf dem Server.

Dann braucht man aber kein DVCS, wenn sowieso jeder sicherstellen
muss, dass zum Zeitpunkt X alles auf dem Server liegt. In meinem
letzten Projekt hieß es immer, mindestens zum Feierabend einmal zu
pushen.

> Denke du missinterpretierst da was.

Nö, im Artikel werden lokale, serverlose Branches doch als Vorteil
herausgestellt, ebenso von vielen anderen DCVS-Fans, die ich so
gelesen habe.

> Die Versionsverwaltung ist doch nicht zur Datensicherung da.

Für die Arbeit eines jeden Entwicklers, natürlich. Wenn ich zentral
committe habe ich das Problem nicht mehr, ausschließlich lokale
Commits sichern zu müssen.

> Gibts in Git keine Ordner oder was meinst du?

Doch, aber nicht für Tags und Co., weil Tags und Co. nur Namen für
Commits sind, in Subversion sind Tags und Co. aber normaler
Bestandteil des versionierten Dateisystems und nur per Definition
speziell. Deswegen kann man in letzterem beliebige
Verzeichnissturkturen für Tags, Branches usw. anlegen, in Git aber
nicht. Das Datenmodell sieht derzeit eben nur eine Ebene von Namen
für Commits vor.

> Ich bezweifle, dass das ueberall so geregelt ist. Warum kann es im
> Tracker keinen zusaetzliches State ala "Ist im Featurebranch
> implementiert" geben?

Die Frage ist doch, wann der Tracker, das Wiki oder was es alles gibt
Änderungen in der Versionsverwaltung mitbekommen kann und das ist
normalerweise nur dann der Fall, wenn ins Master Repo gepusht wurde.
Das ist je nach Strategie usw. eben irgendwann, bei Subversion kann
der tRacker bei jedem Commit aktualisiert werden oder so. Man muss
also im Zweifel damit rechnen, dass die Arbeiten zu einem Bug erst
nach 3 Tagen oder so zum Bug auftauchen, weil erst dann gepusht
wurde. Je öfter man aber pusht, desto geringer der Vorteil eines
DVCS, weil man dann ja im Zweifel wieder Internet benötigt usw.

> Ja und schau mal in Projekten mit vielen Devs, zu welch tollen
> commitlisten das fuehrt. Da kann man fast genausogut einmal pro Woche
> alles zusammen pantschen.

Was für Probleme meinst du denn? In der Regel interessieren einen
doch nur die Commits pro Arbeitseinheit, alsop Branch oder Tag oder
weiß der Geier. Alles interessiert einen doch nur extrem selten.

> Ja, aber mit SVN auch, nur dass da neben der Datensicherung *auch*
> noch die Struktur verloren geht.

Mit Subversion muss man sich immer nur über die Sicherung, Spiegelung
oder so des Repos einen Kopf machen, da dieses alles beinhaltet, was
committed wurde. In aller Regel wird das Ding auf einem zentralen
Server liegen, für den es geeignete Sicherungstrategien gibt usw.,
nicht auf einem lokalen PC. Falls es auf einem lokalen PC liegt, hat
man ggü. Git keinen Nachteil mehr, weil man ja ebenfalls unabhängig
von einem Server agieren kann. Dass man sichd ann um eine Sicherung
kümmern muss, ist klar. In Git ist das Problem aber schräfer, weil es
eben Master-Repos und geklonte Repos gibt und die lokalen Änderungen
bewusst erst mal irgendwann ins Master geschoben werden müssen. Für
dessen Sicherung wird dann auch wieder jemand verantwortlich sien,
wie in Subversion.

> Wie oben geschrieben: Kein VCS ersetzt dir eine Datensicherung.

Die Frage ist aber, an wie vielen Stellen man sich über Sicherung
einen Kopf machen muss. In dVCS muss man es auch am Client oder eine
Puish-Richtlinie implementieren.

> Hat eher mit dem Mergealgorithmus zu tun, als distributed oder nicht.
> Manche VCS bieten eine ganze Reihe moeglicher Algorithmen an.

Meiner Erfahrung nach kann kein VCS da irgendwas machen, sowas muss
geeignet kommuniziert udn dann druchgezogen werden, egal wie groß der
manuelle Eingriffaufwand ist.

Thread-Anzeige einblenden

Anzeige