Subversion und VisualSVN für Ein-Mann-Entwicklung

[Assarbad]

Zitat von Sherlock:

Ich sehe keinen Grund Branches zu löschen. Die gehen doch mit einem Merge ineinander über. Nur wenn man einen Branch reaktiviert geht die Entwicklung darin weiter. So ist zumindest meine Wahrnehmung bei Mercurial. Ausserdem kann man, wenn man es unbedingt braucht, Branches gezielt schließen. Und selbstverständlich besteht auch ein Branch immer nur aus Changesets, nie aus allen Dateien.

Bei Subversion müßtest du solche Entwicklungszweige explizit nach dem Zusammenführen löschen (hab's erst vorgestern wieder machen müssen). Aber viele scheinen davor zurückzuschrecken, weil sie nicht wissen, daß die dann nicht weg sind, sondern nur nicht mehr auf der aktuellen Revision sichtbar. Das war vielleicht ein K(r)ampf meine Kollegen zu überzeugen die uralten Entwicklungszweige bei uns mal auszumisten. Am Ende hab ich's dann einfach gemacht, nachdem ich denen quasi schwören mußte, daß ich an die Dinger im Notfall wieder rankomme.

Hier sieht man diese kranke Vermischung zwischen dem Konzept der Tags/Branches und der Pfade im Repo. Das hat bis auf SVN nur noch Bazaar in einigen Nutzungsszenarien. Ansonsten ist bei den modernen VCS ein Tag und ein Branch immer etwas nicht wirklich "greifbares". Man braucht also andere Operationen als jene die man auch für Verzeichnisse oder Dateien benutzt ("svn copy" etc).

Über die Langsamkeit von SVN könnte ich noch hinwegsehen, immerhin hat es statt wie bei CVS eine globale Revision über das gesamte Repo (wer schonmal versucht hat Infos aus einem CVS-Repo zu kratzen oder dieses zu konvertieren, weiß was ich meine, hunderte einzelne Dateien mit eigener Versionshistorie und Tags/Branches sind nicht immer mit dem gleichen Zeitstempel erzeugt, weil: einzelne Dateien). Aber die Vermischung von Tags/Branches mit Verzeichnissen ist ein aus meiner Sicht schwerer Designfehler. Das wird jeder bestätigen können der schonmal die verrücktesten unbeabsichtigten Fehler erlebt hat wie bspw. aus der Wurzel des Repos zu branchen oder über Entwicklungszweige hinweg einzuchecken (was in keinem anderen VCS geht, weil die Arbeitskopie immer exakt einen Zweig umfaßt).