Subversion und VisualSVN für Ein-Mann-Entwicklung

[Fritzew]

Wir benutzen in etwa das Schema im Anhang.
Bis vor 2 Jahren waren wir auf SVN.
Git hatte eine Lernkurve aber ich muss sagen, ohne möchte ich nicht mehr arbeiten.
Wenn man erst mal mit der Philosophie vertraut ist geht es ganz gut.

[jaenicke]

Im Team macht da finde ich ein solcher Ablauf Sinn:
http://nvie.com/posts/a-successful-git-branching-model/

Bei einem einzelnen Entwickler wird man das eher nicht so konsequent machen.

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

Sherlock

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

[Ghostwalker]

@Assarbad

[OT]Der Prof in deiner Sig, ist das der der den Leuten mitten in der Nacht versucht das Universum zu erklären ?[/OT]

Zum Thema:

Bisher hab ich privat und beruflich immer mit SVN gearbeitet (beruflich in kleinen Teams). Das
hat wunderbar funktioniert.

[Assarbad]

Zitat von Ghostwalker:

[OT]Der Prof in deiner Sig, ist das der der den Leuten mitten in der Nacht versucht das Universum zu erklären ?[/OT]

Das ist er, jupp.

Zitat von Ghostwalker:

Bisher hab ich privat und beruflich immer mit SVN gearbeitet (beruflich in kleinen Teams). Das hat wunderbar funktioniert.

Darf ich fragen wieviele Zweige, Tags und Revisionen so insgesamt? Mit oder ohne Binärdateien? Ich hab's schon in mehreren Projekten hinter mir und aktuell noch in einem aktiven (wobei ich an der Konvertierung mithilfe von reposurgeon arbeite) und jedesmal wurde Subversion irgendwann arg langsam.

[Ghostwalker]

Da es, beruflich, Web-Projekte waren, gabs da nix binäres (Grafiken wurden nicht im SVN gepflegt).

Tags/Zweige gab es nicht viele, Revisionen einige, wurde ja über Jahre auch gepflegt die Software.

Im wesentlich waren es zwei Zweige (einer für den aktuellen Stand auf den Live-Server, einen für die Entwicklung). Gelegentlich mal einen, wenn einer etwas größeres geändert hat oder ausprobieren wollte.

Wieviel Revisionen es nu waren kann ich dir nicht sagen, hab da nie sonderlich drauf geachtet Aber bei 2-3 Entwicklern die über Jahre daran täglich arbeiten kommt da schon was zusammen