Wie Golem die Woche berichtet hat, wurde die Version 1.0 von Mercurial freigegeben. Mercurial ist eine freie, verteilte Quellcodeverwaltung. Schon vor 1.0 wurde sie für zahlreiche Projekte verwendet. Die größten Projekte sind wohl die Sun-nahen Projekte wie NetBeans - by the way - Super RoR-Support - und OpenJDK.
Der größte Unterschied von einem verteilten Quellcodeverwaltungsystemen zu konventionellen wie Subversion ist (meinem Verständnis nach), dass ein Checkout (bei Mercurial Clone genannt) nicht fest mit einem Repository verbunden ist. Änderungen können kurzfristig im Repository A gesichert werden. Aber ein späterer Versionstand kann in eiem anderem Repository B gespeichert werden. Außerdem ist dort das erzeugen einer neuen Version durch Commit von dem Veröffentlichen dieser Änderung entkoppelt. Man kann lokal häufig committen, aber nur fertige Versionen können dann veröffentlich ("pull") werden. Im Mercurial-Wiki ist eine Beschreibung vorhanden.
Warum kann dies nützlich sein?
Zum Beispiel bei Uni-Projekten könnte (mit Mercurial) jeder Student mit seiner Bachelor- oder Diplomarbeit oder jede Gruppe von Studenten ein eigenes (privates) Repository erhalten mit dem er tälich oder stündlich Commits erzeugt. Aber nur funktionierende Versionsstände werden dann in das zentrale Hauptrepository geschoben.
Man könnte so etwas mit Subversion-Branches machen, aber selbst da ist jede "interne" Sicherung auf dem zentralen System sichtbar. Nicht so schön. Faktisch commiten Studenten tälich Zwischenstände ins zentrale Repository, was häufig zu Unannehmlichkeiten führt.* Oder sie arbeiten ohne Sicherung (Commit) bis zum einem Meilenstein, aber viel des Komforts einer Quellcodeverwaltung geht damit verloren. Und bei HD-Crashes verliert man nicht nur dem "Komfort".
In gewisser Weise sind verteilten Quellcodeverwaltungsysteme die dritte Stufe - nach zentralisierten, Sperr-basierten Systemen und zentralisierten, Merge-basierten Verfahren wie Subversion. Ein anderes verteiltes Quellcodeverwaltungssystem ist GIT, dass z.B. für den Linux-Kernel eingesetzt wird.
Ich selbst habe noch nicht mit veteilten Quellcodeverwaltungen gearbeitet, aber ich glaube, dass es z.B. in dem Uni-Kontext wirklich sinnvoll wäre. **
---
* Man kann eine Strategie fahren, dass man nur ein zentrales Repository mit häufigen Commits ohne Branches hat. In enggekoppelten Teams wie in Firmen ist dies wohl auch die Standardvariante. Aber bei lose-gekoppelten Teams wie bei Uni-Projekten ist dies wohl nicht die optimale Idee.
** Ebenfalls für den Einsatz für Studentenprojekten gedacht ist DrProject, eine Trac-Variante für "classroom usage".
No comments:
Post a Comment