Subversion und VisualSVN für Ein-Mann-Entwicklung

[Uwe Raabe]

Zitat von Namenloser:

Das ist das einzige Argument, das ich gelten lassen kann.

Das ist eher ein Argument für Git/Mercurial, weil es nämlich gerade nicht stimmt! Ich habe mal gerade ein SVN-Repo ausgecheckt (SVN 1.8). Der .SVN Folder hat eine Größe von 23 MB und enthält im Wesenltichen die Originale der gerade ausgecheckten Revision (eben eben nur der). Dasselbe SVN-Repo mit kompletter Historie aller Branches in Mercurial konvertiert belegt gerade mal 9 MB im .HG Folder, enthält aber eben die komplette Historie.

In der Regel sind die lokalen Repos eines DVCS deutlich kleiner als die von SVN vorgehaltenen lokalen Daten.

[Daniel]

Am Rande eingeworfen - und das gilt gewiss auch nicht für alle - aber ich erwarte schon eine konstruktive Auseinandersetzung mit dem Thema. Unabhängig davon, ob man nun SVN, Git, Mercurial oder den Ausdruck auf Endlospapier bevorzugt, sollte eine sachliche Diskussion in aller Interesse sein.

[Sherlock]

Ich denke, wir müssen niemanden bekehren. Wer mit seiner gegenwärtigen Arbeitsweise glücklich ist, dem sei es gegönnt. Schließlich kann das nicht jeder von sich behaupten.

Ich würde Neueinsteigern, wie dem TE, halt empfehlen gleich bei State-of-the-Art anzufangen, statt zunächst die Erfindungen des Rades nachzustellen....

Sherlock

[himitsu]

Bei SVN liegt es aber auch nur daran, dass SVN jede Datei einzeln und unkomprimiert im .SVN-Verzeichnis ablegt.
Komprimiert und in einer Archivdatei, da wäre "theoretisch" der Checkout nur einer Revision immer kleiner, als der aller/mehrerer Revisionen. (gleiche Komprimierungsmethode vorausgesetzt)
Allerdings ist im .svn auch nicht von jeder Datei eine Kopie drin. (eventuell gibt es keine Kopie von Dateien, wo man eh keinen Diff anzeigen kann, oder so? )

Man kann dann zwar "theoretisch" schneller auf die Daten der einzelnen Datei zugreifen, aber ingesamt ist das einfach nur 'ne blöde Idee gewesen. (aber schon besser, als das von früher, wo in jedem einzelnen Unterverzeichnis ein keines .svn rumgammelte)

[RWarnecke]

Hallo zusammen,

ich habe nicht alles gelesen. Aber ich gebe meinen Senf auch noch dazu. Ich benutze seit ca. 2,5 Jahren Git. Meine Repositories liegen auf zwei Servern. Der eine Server ist mein Produktionsserver und der zweite Server nur ein Backup, wo ich gelegentlich einen Push gegen absetze, damit dieser wieder auf dem aktuellen Stand ist. Alle Repositories werden so konfiguriert, dass beide Server beim Push oder Commit ausgewählt werden können. Beide Server sind mit Ubuntu installiert. Auf meinem Produktionsserver liegt auch noch ein Apache Webserver der einen Bugtracker beherbergt. Dieser Bugtracker kommuniziert ebenfalls mit den GIT-Repositories und ich kann jeden Commit einem Ticket zuweisen und auch das Ticket schließen. Dazu sind lediglich ein paar Schlüsselwörter notwendig, die ich an den Anfang der Commit-Bemerkung setze. Somit kann ich jederzeit nachvollziehen, was ich wie und wann geändert habe zu welchem Ticket.

Als Client benutze ich unter macOS das Programm SourceTree, welches es ebenfalls für Windows. Das Tool ist übersichtlich und sehr leicht zu erlernen.

Das beste daran ist, die ganze Software hat mich keinen Cent gekostet. Ich zahle lediglich nur meine Gebühr für meinen Produktionsserver der bei einem Anbieter steht.

[sh17]

@RWarnecke welchen Bugtracker nimmst Du?

Alternativ zu einem Server - Man kann git auf einem Synology NAS aktivieren und dieses als remote seinen lokalen repos für gelegentliche pushs hinzufügen.

[RWarnecke]

Zitat von sh17:

@RWarnecke welchen Bugtracker nimmst Du?

Den Mantis Bugtracker mit den folgenden Plugins :

• VCS Basisintegration 1.3.1
• GitHub Integration 1.3.0
• GitLab Integration 1.0.3
• Gitweb Integration 0.18
• Cgit Integration 0.16

Das erste Plugin ist das Hauptplugin. Die restlichen 4 Plugins sind optional und müssen für die entsprechende Variante hinzugefügt werden. Ich selber benutze das Gitweb-Plugin. Das Github ist nur für Repositories auf GitHub.com und das GitLab habe ich garnicht nicht ausprobiert.

[jfheins]

Ich benutze privat gerne git, auf der Arbeit mehr oder weniger gerne SVN. Hat beides seinen Sinn.

Als deutlichen Vorteil von git empfinde ich das lokale Log. Für ein SVN log muss man immer mit den Server verbunden sein. Für diffs der Revisionen sowieso. Bei git braucht man bspw. seinen Server gar nicht ins Internet zu hängen: Wenn der Server nur im LAN ist funktioniert das ganze genau so gut - auch auswärts. (Vll. ein Argument für die Informationssicherheit)
Auf der Arbeit habe ich auch mehrere Netze, sodass man nicht immer an dem LAN hängt wie der SVN Server. Man kann trotzdem das Log einsehen, diffen und comitten

Für das Haupt-Repo würde aber git ehrlicherweise keinen Sinn machen. Das Arbeitsverzeichnis ist 12GB und bekommt jeden Tag 100 commits. Zusätzlich wird SVN als Veröffentlichungstool für die Kompilate genutzt. Zudem ist SVN für neue Kollegen (keine Informatiker) gefühlt einfacher zu lernen.
Und wenn die SSD zu klein wird, kann man auf den .svn-Ordner die NTFS-Komprimierung aktivieren. Hilft etwas.