Subversion und VisualSVN für Ein-Mann-Entwicklung

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

Zitat von Sherlock (Beitrag 1353186)

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:

Zitat von Ghostwalker (Beitrag 1353319)

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

Zitat von Ghostwalker (Beitrag 1353319)

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 :)

[himitsu]

Einmal hatten wir bei SVN ein Problem, aber das gibt es wohl in allen Versionssystemen.

Irgendwie hatte SVN beim Einchecken mehrere Binärdateien als "Text"erkannt/markiert, was bei den "Zeilenumbrüchen" dann die Dateien schrottete.
Als wir dann erstmal rausfanden (dauerte etwas), dass diese Dateien "defekt" waren, half am Ende nur löschen und erneut adden.

[Assarbad]

Zitat:

Zitat von Ghostwalker (Beitrag 1353324)

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 :)

Cool, Danke für die Info. Mit nur zwei Zweigen gibt man SVN natürlich auch weniger zu tun. Aber finde es schon faszinierend, daß es für einige hervorragend zu funktionieren scheint, und bei uns immer ab irgendeinem Punkt performancetechnisch absackte. Wobei sich die drei Repositories die ich im Sinn habe alle mehr oder weniger in der Nutzung und Ausmaß an Revisionen und Tags/Branches ähneln.

Zitat:

Zitat von himitsu (Beitrag 1353325)

Irgendwie hatte SVN beim Einchecken mehrere Binärdateien als "Text"erkannt/markiert, was bei den "Zeilenumbrüchen" dann die Dateien schrottete.
Als wir dann erstmal rausfanden (dauerte etwas), dass diese Dateien "defekt" waren, half am Ende nur löschen und erneut adden.

Jupp, ist auch einer der Fehler die von CVS auf SVN portiert wurden. Nicht vergessen, die Autoren von SVN hatten es ja als Nachfolger von CVS im Sinn, der viele alte Fehler nicht macht (scheinbar aber viele neue). Aus meiner Sicht geht es ein VCS nichts an wie die Dateiendungen aussehen. Das darf und soll das komplett clientseitig (also in der Arbeitskopie) gelöst werden und betrifft ohnehin nur wenige Dateien. Auch Windowsentwicklungswerkzeuge kommen mit LF statt CRLF klar.

Übrigens, SVN-Externals finde ich noch so ein abgrundtief grottiges "Feature". Aus zwei Gründen:

1. Wenn ich Externals in meine Arbeitskopie auschecke, will ich auch in der Lage sein darin Änderungen vorzunehmen, insbesondere wenn es sich um repo-relative oder server-relative Externals handelt. Denn es steht ja anzunehmen, daß ich bei einem relativen External der auf dem gleichen Server liegt auch Zugriff hab. Und sollte das nicht der Fall sein, kann SVN das immernoch an meinen Zugriffsrechten scheitern lassen. Aber so erleichtern Externals, in Zeiten in denen ich ganz leicht auch auf Windows nen Junction-Point oder ne symbolische Verknüpfung anlegen kann, die Arbeit nur scheinbar.
2. Absolute Externals können scheinbar nachträglich nicht ohne dump/filter/load-Routine auf alten Revisionen geändert werden, was ein echtes Problem darstellt. Wenn sich Servername, Pfad zum Repo oder auch das Protokoll geändert haben und die jeweils alte Einstellung nicht mehr funktioniert, hat man damit einen alten Zustand den man nicht mehr nutzen kann. Soviel dann zum Thema reproduzierbare Kompilate. Fazit: Externals außerhalb des eigenen Servers vermeiden, ggf. die externen Repos mit svnsync spiegeln (und nicht vergessen die UUID anzupassen).

[galex9]

Wie ich sehe dieses Thema ist ziemlich heiß.

Meine Meinung nach zur Entwicklung gehört nicht nur VCS sondern auch ein Bugtrackingsystem. Auch für Ein-Mann-Entwicklung!

Hier wurden schon viele VCS Systeme diskutiert: SVN, GIT, Mercurial.

Ich möchte euch noch ein vorstellen: Fossil https://www.fossil-scm.org. Klein, schlang mit Bugtrucker und Wiki. Wird unter anderem von Synopse verwendet.

Schaut euch das mal an.

[Assarbad]

Zitat:

Zitat von galex9 (Beitrag 1353349)

Meine Meinung nach zur Entwicklung gehört nicht nur VCS sondern auch ein Bugtrackingsystem. Auch für Ein-Mann-Entwicklung!

Das unterschreib ich sofort!

Zitat:

Zitat von galex9 (Beitrag 1353349)

Ich möchte euch noch ein vorstellen: Fossil https://www.fossil-scm.org.

Benutzt du es aktiv? Erzähl mal von deinen Erfahrungen! Ich habe es mir auch schon angeguckt, genau wie Veracity vom Autor von VCBE -- immerhin ist Fossil vom gleichen Autor wie SQLite3 was die meisten von uns auf dem Computer, im Handy und im Auto unbemerkt laufen haben. Fossil hinterlegt ja auch alles in einer SQLite3 Datenbank.

Beim letzten Mal fand ich, daß es gefährlich sein könnte auf dieses VCS/SCM zu setzen, weil ich keine Methode gefunden habe um in ein anderes VCS zu konvertieren. Man würde sich also einmauern. Gibt's da mittlerweile etwas? Auch gab es damals dafür meines Wissens nach keine ähnlichen Werkzeuge wie die Tortoise-Reihe. Hat sich das vielleicht auch schon geändert? Bei uns in der Firma benutzen beispielsweise auch die wenigsten die Befehlszeile; sondern setzen auf grafische Werkzeuge. Vermutlich der Hauptgrund warum Git überhaupt von so vielen Leuten als benutzbar angesehen wird :mrgreen: