Subversion und VisualSVN für Ein-Mann-Entwicklung

[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

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

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

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 von galex9:

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

[galex9]

Zitat von Assarbad:

Benutzt du es aktiv?

Ehrlich gesagt ich teste es zur Zeit.

Zitat von Assarbad:

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?

Ja. Nur z.Z. auf Konsole https://www.fossil-scm.org/xfer/doc/...www/inout.wiki

Zitat von Assarbad:

Auch gab es damals dafür meines Wissens nach keine ähnlichen Werkzeuge wie die Tortoise-Reihe

Ich hatte bis jetzt zwei die mir mehr oder weniger passen gefunden: Fuel und BoneCollector4Fossil. Und schon mit Gedanken gespielt selbst etwas zu schreiben.

[Assarbad]

Zitat von 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

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 von himitsu:

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