[linux-l] Re: VCS

Volker Grabsch vog at notjusthosting.com
Do Apr 6 14:31:16 CEST 2006


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.

> Dazu kommen dann doch sicherlich noch viele Detail-Probleme, wie z.B.
> folgendes.
> Wenn ich z.B. kein $Header$ hab (und es muss genau $Header$ und $Name$
> sein, weil das ja so in den Sourcen steht), kann ich an den Files nicht
> 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". 

> Wie geht
> man mit Leuten um, die nicht so sorgfältig arbeiten?

Ich weiß, dass es eigentlich zum Thema Zensur war, aber an dieser Stelle
ist es auch passend:

"Gesellschaftliche Probleme lassen sich nicht durch technische Maßnahmen
lösen".

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.

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

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

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

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

Subversion soll irgendwann auch noch "Merges" automatisch verwalten,
dieses Feature suchst du. Oder, wiegesagt, nimm gleich ein changeset-
orientiertes VCS.

> 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? Da hat man natürlich ne Menge Rennereien.


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR



Mehr Informationen über die Mailingliste linux-l