Hallo zusammen,
ich entwickele seit etwa 15 Jahren fast durchgehend mit RCS, CVS, SVN und Mercurial. Aktuell bevorzuge ich Mercurial und würde kein Projekt mehr mit RCS, CVS oder SVN anfangen. Wenn, würde ich GIT statt Mercurial verwenden.
Kurz zu den Unterschieden der Systeme:
RCS, CVS und SVN verwenden einen zentralen Server. CVS kann alles nur online, SVN kann darüber hinaus die aktuellen Änderungen (einen "diff") auch offline anzeigen und damit auch einen "revert", d.h. zurück zur Ursprungsfassung.
Mercurial, GIT, Bazaar, Monotone, Arch & Co sind verteilte Systeme. Hier braucht man keinen zentralen Server, es empfiehlt sich aber wärmstens. Bei diesen Systemen kann man ohne Kontakt zum zentralen Server alles machen, was die anderen nur online können, d.h. add/remove/commit/revert/update/log usw. Es gibt zwei zusätzliche Befehlen "push" und "pull", mit denen Änderungen zu einem anderen Server übertragen werden können.
Nun zu dem Thema Branches:
CVS und SVN können Branches, jippihayey! Das hilft aber in der Praxis nicht wirklich, denn was sie nicht (oder zumindest nicht benutzbar) können ist, zwei Branches wieder zu vereinen (Merge). Damit bringt ein Branch nicht viel (außer vielleicht eine Version zu archivieren), wenn man die zwei Zweige nicht mehr zusammenbringen kann. Ich habe Tag damit verbracht, ein svnmerge ohne Konflikte zum Laufen zu bringen. Es sieht zuerst so aus, als ginge es, aber wenn wirklich mehrere Entwickler mit eigenen Zweigen arbeiten und sich regelmäßig synchronisieren wollen, dann die kurze Zusammenfassung: es klappt nicht.
Mit Mercurial & Co sieht das ganz anders aus. Das Kern-Feature der verteilten Systeme ist nicht das Verteilen/Branchen, sondern der Merge. Kurze Zusammenfassung: es klappt! Und zwar richtig, immer, überall und auch wenn man zwischen den Entwicklern alles kreuz und quer synchronisiert. Warum klappt es? Weil sich die Verteilten Systeme merken, was wo wie synchronisiert wurde. CVS und SVN vergessen diese Information nach einem Merge und damit entsteht das Unglück. Die aktuelle SVN-Version hat etwas aufgeholt, aber es ist einfach nicht in dem Basiskonzept enthalten.
Wer die Unterschiede ausführlicher und mit sehr viel Hähme gewürzt erklärt bekommen will, der schaut sich diesen Vortrag von Linus Torvalds über GIT an:
http://www.youtube.com/watch?v=4XpnKHJAok8
"Und was ist mit GIT"?
Wie beschrieben verwende ich Mercurial und nicht GIT. Die beiden Systeme sind aber von Vorgehensweise gleich und deshalb recht gut vergleichbar. Mercurial ist in Python geschrieben, Git in C. Git wird von den Linux-Kernel Entwicklern entwickelt und ist darauf hin optimiert, Linux-Kernelcode zu verwalten. Die Unterschiede zu Mercurial: Git ist unter Linux ca. 10x schneller als Mercurial. Dies bedeutet, dass 3MB Quellcode inkl. ca. 2.000 Änderungen mit Mercurial in ca. 2s ausgecheckt sind, während Git es in 200ms hinbekommt. Für mich bedeutet dies keinen signifikanten Unterschied. Git war erst später unter Windows verfügbar und soll auch nicht so schnell sein. Die Integration von Mercurial in Entwicklungsumgebungen ist weiter fortgeschritten, als die von Git. Man sollte also prüfen, ob die verwendete Entwicklungsumgebung Git unterstützt. Die Entscheidung Git oder Mercurial ist aber gar nicht so schwerwiegend, denn es gibt Tools, die von einem in das andere Format konvertieren können, also das komplette Repository inkl. allen Änderungen.
Nun zu den Fragen:
dixidix hat geschrieben:
Brauchen wir regelmäßige Releases oder reicht HEAD?
Releases sind auf jeden Fall sinnvoll, um regelmäßig zu einem "stabilen Stand" zu kommen, auf dem anderen Entwickler aufsetzen können.
dixidix hat geschrieben:
Wie sinnvoll sind für uns Branches?
Wenn man ein Verteiltes System verwendet, dann stellt sich die Frage nicht. Jeder Entwickler hat automatisch seinen eigenen Branch, der regelmäßig mit anderen Branches abgeglichen wird. Ein Branch auf einem zentralen Server wird üblicherweise als der "Hauptzweig" bezeichnet. Rein technisch ist das lediglich eine Definition.
Dies hat auch Vorteile, wenn es mal zu einem "Fork" eines Projektes kommt. Da kein Repository wirklich der "Chef" ist, kann man die zwei Teile jederzeit wieder zu einem Projekt vereinigen und das sogar ohne dass man sich darüber einig werden muss, welcher Repository-Server weiterverwendet und welcher entfernt wird. Es gibt einfach zwei gleichberechtigte Pfade, die wieder vereint werden. Man sieht der History später nicht an, wer "gewonnen" hat, da es so etwas gar nicht gibt.
dixidix hat geschrieben:
Ist ein Experimentier-Branch die AllInOne-Lösung?
Bei Verteilten Systemen sind Branches "billig". Und Merges trivial. Macht jedes Feature in einen Zweig, dazu einen AllInOne-Zweig, gerade so, wie es einem in den Sinn kommt. Es ist alles vollkommen einfach zu handhaben.
dixidix hat geschrieben:
Welche Vor-oder Nachteile würde das bringen?
Wenn man einen "stabilen Zweig" hat, dann weiß man als Entwickler, dass seine eigenen Änderungen und nicht die eines anderen Entwickler Probleme in der gerade von ihm getesteten Version macht.
dixidix hat geschrieben:
Reicht uns die bisherige reine "Patch-Methode"?
Die Verteilten Systeme machen das überflüssig. Patches lassen sich jederzeit automatisch generieren, sind aber auch nicht wirklich notwendig.
dixidix hat geschrieben:
Wann wäre welche Methode angebracht?
Mit den verteilten Systemen hat man die freie Wahl, wie man vorgeht.
dixidix hat geschrieben:
Wie würde eine Koexisistenz von mehreren Versionsverwaltungssystemen aussehen?
Man braucht zwei zentrale Systeme, die regelmäßig synchronisieren.
dixidix hat geschrieben:
Geht das überhaupt?
Ja, sofern man keine der etwas esoterischen Features nutzt, die in dem jeweils anderen System nicht 1:1 existieren.
Meine Empfehlung deshalb:
Verwendet Git oder Mercurial und vergesst CVS und SVN.
Soviel von meiner Seite dazu. Ich lese das Forum eher zufällig, deshalb bei Fragen am besten Mail an kurt bei huwig.de.
finde ich super 
