Subversion und VisualSVN für Ein-Mann-Entwicklung

[Aviator]

Zitat von Sherlock:

Nicht umsonst hat MS sehr viel Zeit und Energie in die Powershell gesteckt.

Haha. Das ist wohl wahr.

Ist zwar etwas OT, aber ich habe anfang des Jahres (und auch jetzt immer mal wieder) einen neuen Exchange 2016 eingerichtet. Es geht zwar sehr vieles über das Exchange Admin Center, aber einige "tiefer" greifende Systemeinstellungen kann man nur über die Exchange Management Shell (welche auf der PowerShell basiert) einrichten.


Aber um noch etwas zum Thema beizutragen:

Ich benutze auch seit etwa 1 - 1,5 Jahren eine Versionsverwaltung. Anfänglich SVN, jetzt GIT. GIT hat wohl einige Vorteile, hat mir aber auch schonmal ganz übel mein Projekt zerschossen. Wahrscheinlich eher aus Unwissenheit meinerseits, aber das hat mich wirklich geärgert. Hatte dann schon einige Stunden Zeit gekostet, bis ich meinen aktuellen Stand wieder hatte.

Mein Problem bei einer Versionsverwaltung ist immer, dass ich vergesse etwas einzuchecken wenn ich etwas gelöst habe. Auch mit dem Branching habe ich so ein Problem. Wann lege ich einen an und wann nicht? Oder lösche ich bestehende Branches nochmal oder lasse ich die für alle Zeiten stehen?

PS: Auch ich arbeite nicht im Team, sondern alleine. Trotzdem würde ich jetzt sagen, dass es sich schon lohnt. Benutze allerdings nicht die GIT Shell, sondern SourceTree.

[jaenicke]

Zitat von Aviator:

Auch mit dem Branching habe ich so ein Problem. Wann lege ich einen an und wann nicht?

Das lohnt sich nur, wenn du eine längere Entwicklung, z.B. ein neues Feature, machst und daneben noch etwas anderes an dem Projekt machst. Zum Beispiel auch einen Bug analysieren.
Wenn du das neue Feature dann in einem eigenen Branch hast, kannst du mit dem unveränderten Projekt debuggen usw. und mergst das neue Feature dann erst am Ende in den Master-Branch.

[Aviator]

Zitat von jaenicke:

Zitat von Aviator:

Auch mit dem Branching habe ich so ein Problem. Wann lege ich einen an und wann nicht?

Das lohnt sich nur, wenn du eine längere Entwicklung, z.B. ein neues Feature, machst und daneben noch etwas anderes an dem Projekt machst. Zum Beispiel auch einen Bug analysieren.
Wenn du das neue Feature dann in einem eigenen Branch hast, kannst du mit dem unveränderten Projekt debuggen usw. und mergst das neue Feature dann erst am Ende in den Master-Branch.

Alles klar. So hatte ich es bisher auch zum Großteil gemacht. Löschst du denn die Branches danach immer wieder nachdem du gemergt hast? Wäre ja irgendwie sinnlos den zu behalten, weil der letzte Commit ja dann u.U. sowieso nicht mehr gültig wäre, oder?

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