[linux-l] Re: VCS

Steffen Dettmer steffen at dett.de
Sa Apr 15 00:21:52 CEST 2006


* Volker Grabsch wrote on Thu, Apr 06, 2006 at 14:31 +0200:
> On Wed, Apr 05, 2006 at 10:08:22PM +0200, Steffen Dettmer wrote:
> > CVS hat so seine Macken, je nach Version (und wir benutzen extra eine
> > alte), da wünscht man sich manchmal schon etwas anderes. Was dann
> > vermutlich andere Macken hat, oder? 
> 
> Mag sein, aber vergiss nicht die vielen Macken von CVS, die man
> vielleicht gerade nicht wahrnimmt, weil sie von den großen Macken
> überschattet werden.
> 
> Diese dämliche "jede Datei hat ihre eigene Version" hat kein anderes
> VCS, und davon loszukommen ist schon für sich ein riesen Schritt,
> egal ob du nun Subversion, Mercurial oder GIT nimmst.

Warum denn nur? Was hat das denn für eine Vorteil, dass man keine Nummer
hat/sieht? Mich stört die Nummer nicht. Es gab sogar hin- und wieder
Fälle, da hab ich sie benutzt.

Eine Macke ist, dass "cvs log -r -r" und "cvs annotate -r" nicht
funktionieren.

> > erkennen, auf welcher Revision (oder Anker oder wie auch immer man das
> > nennt) es basiert und nach Änderungen schlecht "einsortieren".
> 
> In keiner Versionskontrolle außer CVS muss man Änderungen
> "einsortieren". 

Siehe mein Beispiel in anderer Mail.

Klar, wenn /alle/ Zugriff auf das SCM haben, hat man das Problem nicht,
aber das ist halt der Unterschied zwischen Theorie und Praxis :)

> > Wie geht man mit Leuten um, die nicht so sorgfältig arbeiten?
> 
> Wenn die Entwickler mit Konflikten nicht umgehen können, muss man es
> ihnen beibringen. Wer's dann immer noch nicht packt, hat den falschen
> Job.

Es gibt nun mal sehr gute und weniger gute Entwickler. Vielleicht kommt
der eine nicht so gut mit CVS klar, aber kann dafür prima Designen oder
so.

> > Bei CVS kommt es hin- und wieder vor, dass Änderungen aus Versehen
> > überschrieben werden,
> 
> Achso? Ist mir noch nie passiert. In solch einem Fall gibt es stets
> einen Konflikt.

Wieso, spätestens wenn Du ein Backup einspielst, kann es zu sowas
kommen.

> > merge-Konflikte falsch gelöst werden und dergleichen.
> 
> Keine Versionskontrolle kann Merge-Konflike für dich lösen. Jedes
> Handbuch zu jedem VCS wird dir sagen:
> 
> Erste Maßnahme bei Konflikten: Kommunizieren.
> 
> Triviale Konflikte kann man schnell selbst lösen, aber das ist die
> Seltenheit. In allen anderen Fällen sollte man sich beraten, da der
> Konflikt meist eine tiefere Ursache hat.  (z.B. ein Absprache-Problem)

Jajaja, das ist wieder so eine Theorie-Aussage...

In der Praxis ist es so, dass in eine Funktion hinzugefügt wird:

/* abort if NULL */
if (hallo == NULL) {
   return someError;
}

und beim mergen nimmt man das mit rein, weil's gut aussieht. Aber
vielleicht wurde es rausgenommen, weil hallo == NULL den
Default-Parameter intern auswählt und der Abbrucht falsch ist. Da hilft
keine Kommunikation, weil man gar nicht auf die Idee kommt, dass man
gerade Mist baut.

Gut, erfahrene Entwickler löschen die Condition nicht einfach, sondern
kommentieren 

/* hallo == NULL is OK and leads to usage of default value */

vielleicht, aber sowas passiert halt.

Da gibts natürlich noch viele andere Beispiele, jedenfalls machen
Menschen immer Fehler. Kommunizieren ist kein Allheilmittel.

Sorry, aber das musste ich mal loswerden. :-)

> > Klar, einfach einchecken geht, aber wenn man in einen 12 Monate alten
> > Branch 5 Fixes einzeln reinmergen soll, sieht das schnell anders aus.
> > "cvs history" ist IMHO schon kaum zu gebrauchen - wird das bei
> > dezentralen CMs, also distributed SCMs schlechter oder besser?
> 
> Allte anderen SCMs haben brauchbare Histories, und erzeugen i.d.R.
> gut lesbare Changelogs.
> 
> CVS ist die Ausnahme, da hier jede Datei ihre eigene History hast.
> Das macht die Verwaltung sehr kompliziert. Jedes andere VCS ist da
> 100x besser, egal ob versions- oder changeset-orientiert.

Ja, OK, das klingt nach einem Vorteil. Aber wieder zu mindestens 50%
theoretisch, weil die ChangeLog's Dateien sind, die manuell vom
Entwickler gepflegt werden, eine geringfügig andere Sicht und vor allem
ein anderes Detailierungslevel haben. Beispielsweise ist egal, wer was
geändert hat usw. Da man Changes/ChangeLog eh manuell pflegt, braucht
man log ja nur im "Falle eines Falles", ist hier eh meist schon auf der
entsprechenden Datei zu gange und der Nachteil stört also nicht so.

Kann natürlich sein, dass meine Arbeitsweise durch das CVS versaut ist,
und dass man das mit anderen SCMs ganz anders und effizienter machen
würde - *das* wäre ein schöner Grund, ein anderes zu verwenden, wenn es
einem weniger Arbeitsabläufe "aufzwingt", als CVS dies tut.

> > Migration in einer Umgebung, wo Reproduzierbarkeit gefordert ist,
> > ist auch nicht einfach. Alte Versionen der Buildumgebung verwenden
> > ja CVS - lässt man das also weiter parallel laufen, damit man alte
> > Versionen bauen kann? Geht vermutlich nicht anders. Dann muss man
> > die Build-Scripte anpassen und in alle Branches mergen usw.
> 
> Bei diesen Problemen spielen die changeset-orientierten VCS ihre
> Stärken aus. Aber mit Subversion geht das auch ganz gut. (jedenfalls
> besser als mit CVS)

Bei der Migration? Wie das? Automatischer CVS-Fallback?!

> > Wir haben mal ein paar Repositories auf einen extra Server gelegt
> > (vorher hatten wir alle auf dem selben host). Dieser Server heisst
> > dann für verschiedene auch noch unterschiedlich. Das alles
> > durchzuführen hat schon einiges an Arbeit gemacht und es gab
> > überraschend viele Stellen, wo was geklemmt hat.
> 
> Versteh ich das richtig? Kein gemeinsamer DNS-Namen für wichtige
> Server?  Wo gibt's denn sowas? 

Na ja, ist halt interner Server, für Windows-Domains in anderen Ländern
des Konzerns heisst er wohl anders (keine Ahnung, wir haben denen dann
die IP gegeben, weil DNS nicht so richtig stabil war zu der Zeit), vom
Internet aus gibt's den Servernamen sogar überhaupt nicht.

Inwzischen läuft eigentlich alles über VPN, also egal, aber
funktionieren muss sowas, sonst kommt man in Teufelsküche. Für CVS haben
wir ein Script, was rekursiv die Servernamen in CVS/Root ändert. Wenn
man binärformat-Files da hätte, hätte man schon verloren, oder?

> Da hat man natürlich ne Menge Rennereien.

Ja, wäre ja sonst langweilig. Aber mir ist erklärt worden, dass das
alles Vorteile vom Defective Actory, ähh, vom Active Directory sind. Na
ja, wenn das so ist, ist das halt so lol

oki,

Steffen

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




Mehr Informationen über die Mailingliste linux-l