[linux-l] Re: VCS

[Volker Grabsch]

On Sat, Apr 08, 2006 at 03:15:39AM +0000, Rocco Rutte wrote:
> * Volker Grabsch [06-04-05 15:27:27 +0200] wrote:
> >Ja, das ist klar. Von daher ist Subversion auf jeden Fall einfacher als
> >CVS. Keine Frage. Die separaten Versionsnummer waren totaler Quatsch,
> >Überbleibsel vom RCS.
> 
> So blöd finde ich das gar nicht. Das einzige wo es nerven kann, ist wenn 
> man irgendwo ein CVS Head benutzt und etwas nicht geht. Bei subversion 
> profitiert man andererseits auch nur wirklich davon, wenn man bei jedem 
> Checkin wirklich nur einen Punkt abarbeitet, sonst hat man nichts 
> gewonnen und muss ja auch wieder in den Logs und Diffs suchen, welches 
> Delta etwas kaputt macht.

Ja, aber was hat das mit CVS/Subversion zu tun?

Natürlich sollte jeder Commit eine extra, abgeschlossene Aufgabe lösen.
Mehrere Tätigkeiten sollten in mehrere Commits aufgespaltet werden.

Das ist eine grundsätzliche Sache. Wenn man das missachtet, macht man
jede Versionsverwaltung unbrauchbar.

Sicher, wenn jede Teilaufgabe in einer anderen Datei wäre, dann wären
die extra Nummern von CVS in diesem Fall eine "Erleichterung" ... IMHO
sind das aber nur Ausartungen von etwas, das an früherer Stelle (beim
User/Entwickler) schon schiefgegangen ist.

Auch in Subversion hindert dich niemand daran, jede Datei einzeln
zu committen. Du kannst auch nur eine bestimmte Gruppe von Dateien
committen.

Darcs ermöglicht sogar, dass man sich alle "Hunks" (Änderungsstellen)
innerhalb der Dateien ansieht, und bei jedem "commit" (dort: "record")
auswählt, welche Hunks aus welchen Dateien man haben will. Das erleichtert
es ungemein, saubere Patches zu erstellen. Dann stimmen Log-Message und
tatsächliche Änderungen perfekt überein, und man bekommt ein ganz anderes
Gefühl dafür als in Subversion/CVS, wo es im Wesentlichen "rein ins VCS
und weg damit" heißt.

Klar, könnte man auch für jedes Feature ein extra Arbeitsverzeichnis
öffnen, in CVS/Subversion ist das besonders zu empfehlen. Aber sehr oft
passiert es einem, dass man eine Datei für ein bestimmtes Feature
bearbeitet, und einem dort nebenbei noch ein paar Bugs oder
Unsauberkeiten auffallen, die man gleich mit fixt.

Wenn man diese Änderungen dann nachträglich auseinanderhalten kann,
ist das eine enorme Erleichterung, weil man sich nicht aus seinem
Arbeitsfluss reißen muss. Mann braucht nicht extra in eine andere
Arbeitskopie zu gehen.

In diesem Fall gewöhnt man es sich in CVS/Subversion leicht an, diesen
Bugfix zusammen mit dem neuen Feature zu committen, plus vielleicht
noch irgendwelche Änderungen. Der commit wird überladen, und manchmal
schreibt man diese Sachen noch nichtmal in die Log-Message, weil sie
so mikrig im Vergleich zum eigentlichen Feature sind.

Ein besseres Bewusstsein dafür habe ich erst entwickelt, als ich
anfing, Darcs zu benutzen. Ich glaube, es liegt dort weniger daran,
dass es changeset-orientiert ist. Diese kleine Feature, dass man
bei einem Commit alle Änderungen interaktiv auswählen kann, das hat
bei mir zum Umdenken geführt. Sowas könnte der Subversion-Client auch
mal unterstützen. :-)

Unsaubere Commits auseinanderzudröseln wird einem in CVS nur dadurch
"erleichtert", dann man es schonmal zwangsweise in Dateien aufgedröselt
vor sich hat. Aber eigentlich werden sie dadurch nur noch schwieriger zu
erkennen, vorallem wenn sich Feature-Implementierungen und Nebenbei-
Änderungen auf mehrere Dateien verteilen.

Kurz: Ich sehe hier keinen ernsthaften Vorteil von CVS gegenüber
Subversion, sondern eher das Problem, dass die von dir geschilderten
Entwickler allgemein mit ner Versionskontrolle noch nicht sauber
genug umgehen.

> >Aber wie sieht das bei dir mit patch-basierten VC-Systemen aus?
> 
> Ich benutze keine, weil ich sie nicht brauche bzw. mir mit subversion 
> nichts fehlt. Ich arbeite quer über verschiedene Maschinen und will da 
> aktuelle Workincopies haben, d.h. für mich ist ein zentraler Server mit 
> ein paar for-Schleifen in einem Makefile optimal, um immer alles 
> synchron zu halten.
> 
> Zum anderen finde ich zentralen schön, dass man die ganzen Hooks nur 
> wirklich einmal konfiguriert und niemand kommt daran vorbei. ;-)

All das hast du bei Darcs auch.

Ein Repository liegt auf dem Server, jeder Entwickler hat dann nochmal
sein eigenes Repository. Also wie Subversion, nur dass Client und Server
relativ ähnlich aussehen. Diese Symmetrie hat aber ne Menge Vorteile.

In Darcs kannst du auch Hooks setzen, und egal ob jetzt was per Mail,
SSH-Zugriff, etc. reinkommt, wird es dann ausgeführt.

Wenn der Zugriff auf das Repository via SSH passiert, ist es sogar fast
dasselbe wie Subversion.

Willst du hingegen HTTPS+WebDAV+Versionskontrolle, dann hat Subversion
die Nase vorn, weil solche Apache-Module für Darcs noch nicht entwickelt
wurden.

Dennoch gibt es auch ein CGI-Script für Darcs.

Andere dezentrale VCS sind hier vielleicht stärker. Darcs wurde an
dieser Seite mit Absicht sehr leichtgewichtig ausgestattet. (per
SSH von einem Respos zum anderen (push und pull), oder per EMail,
das war's)

> >Sind Darcs,Mercurial,QIT schwerer zu verstehen als Subversion?
> >(für einen Anfänger)
> 
> Weiss ich nicht. Woran will man das auch messen? Zu allen Systemen 
> sollte man die Doku lesen und will schnelle Einstiegshilfen finden.  
> Danach wird sich früher oder später dann abzeichnen, ob man selbst mit 
> den Macken des benutzten Systems (und alle haben ja welche ;-) leben 
> kann oder nicht.

Dennoch ist es ein Unterschied, ob man immer seine Änderungen mit
dem Server synchron hält, oder ob man eine Liste von Patches bei
sich hat, die regelmäßig auf dem Server landen.

Letzteres ermöglicht Arbeitsweisen, die z.B. mit Subversion undenkbar
kompliziert wären. Andererseits muss man sich erst daran gewöhnen.

Ich persönlich habe mich sehr schnell umgewöhnt, und komme mit beiden
sehr gut klar. Wenn ich aber z.B. mit Darcs statt CVS angefangen hätte
(gab's aber damals nicht ;-)), vielleicht hätte ich dann einen
schwereren Einstieg gehabt. Oder einen viel besseren, leichteren, sodass
ich nach Darcs einen viel besseren Zugang zu den Macken und Komplexitäten
von CVS bekommen hätte. Wer weiß ...

Daher interessieren mich Erfahrungswerte, die diejenigen gesammelt
haben, die anderen den Umgang mit einer Versionskontrolle beibringen.

Sollte man einem Anfänger erstmal Subversion vorsetzen, und später ein
changeset-basiertes? Oder lieber gleich ein changeset-basiertes von
Anfang an?

> Ich denke, dass es für einen wirklichen Anfänger eher schwerer ist zu 
> verstehen, wann man warum überhaupt ein VCS braucht und so komisches 
> Zeugs wie Tags und Branches... ;-)

Na gut, Tags und Branches, darum kümmert sich der Maintainer, also
i.d.R. nur eine einzige Person im ganzen Team. Die "tägliche Arbeit"
erfordert viel weniger Hintergrundwissen.

Aber jeder, der mal etwas ernsthaftere Sachen geschrieben hat
(> 1000 Zeilen), kenn doch sicher die Angst vor Änderungen. Das führt
dazu, dann man sich vor kritischen Änderungen eine Kopie der Datei
anfertigt, die man gleich bearbeitet. Oder dass man sogar sein ganzes
Projekt nochmal kopiert.

Am Ende liegen dann haufenweise Kopien, Versionen, etc. verstreut
herum. Hat man dann eine Versionskontrolle, die einem den Rücken stärkt,
kann man viel entspannter an die Sache herangehen. Einfach drauflos.
Hat man's übertrieben, lässt man die Datei "wiederherstellen" (svn
revert) und alles läuft wieder. Diese praktische Erfahrung ist IMHO
der Grund, warum jeder, der einmal ein VCS eingesetzt hat, nie wieder
davon loskommt. :-)

Die Vorteile für Teams würde ich erst an zweiter Stelle nennen, denn
die sind für einzelne Entwickler weniger überzeugend. Und wenn ein
Entwickler auch zu Hause ein VCS verwendet, wird er in der Firma viel
besser mit dem VCS umgehen.

Zum Team: Schon allein wenn zwei Leute an einem Projekt arbeiten,
gleichzeitig, aber asynchron, dann zahlt sich ein VCS wirklich aus.
Es nimmt einem viel Stress ab, wenn man nicht mehr so viele Dateien
und Patches per E-Mail umher sendet.

Selbst wenn ich bei ner freien Software einen Bug fixe, und keinen
Zugang zu ihrer Versionskontrolle habe, selbst dann verwende ich
intern eine. Auch wenn ich es nur zum Erzeugen von 2 oder 3 Patches
benutze, ist es viel bequemer als extra Verzeichnisse und "diff" und Co.

Kurz: Auch die persönlichen Vorteile eines VCS snid schon Grund genug,
sich darin einzuarbeiten. Team-Vorteile, Releases, Branches sindnatürlich
auch sehr wertvoll.


Viele Grüße,

    Volker

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