Delphi-PRAXiS - Subversion und VisualSVN für Ein-Mann-Entwicklung

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)

- Sonstige Werkzeuge (https://www.delphipraxis.net/63-sonstige-werkzeuge/)

- - Subversion und VisualSVN für Ein-Mann-Entwicklung (https://www.delphipraxis.net/190770-subversion-und-visualsvn-fuer-ein-mann-entwicklung.html)

AW: Subversion und VisualSVN für Ein-Mann-Entwicklung

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.

AW: Subversion und VisualSVN für Ein-Mann-Entwicklung

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

AW: Subversion und VisualSVN für Ein-Mann-Entwicklung

Zitat:

Zitat von sh17 (Beitrag 1352913)

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

AW: Subversion und VisualSVN für Ein-Mann-Entwicklung

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

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.

AW: Subversion und VisualSVN für Ein-Mann-Entwicklung

Hallo,

Zitat:

Zitat von Namenloser (Beitrag 1352881)

Das "veraltete" Git ist neuer als Subversion.

Ich habe niemals behauptet das Git veraltet oder älter ist als SVN ist! Ich habe lediglich gesagt das einige Konzepte hinter Linux und dort kommt laut meinem Kenntnisstand Git her und man erkennt das deutlich, aus meiner Sicht veraltet sind. Und da meine ich im Falle Git dieses alles ist eine Datei-Konzept (müsste heut alles ist ein Objekt sein) und dieses Konsolenlastige. Ich habe doch keinen Monitor mit Millionen von Pixeln, welche bald Milliarden verschiedener Farben anzeigen können, um mich dann wieder mit Textoutput rumschlagen zu müssen.

Zitat:

Zitat von Namenloser (Beitrag 1352881)

Selbst das gesamte Repository des Linux-Kernels mit allen seinen Änderungen seit 2005 (!) ist gerade mal 1.5 GB groß.

Das ist ja mal eine Info. Ohne zu wissen hätte ich gedacht die haben mehr. Ist da alles vom ersten Anfang mit dabei? Oder habe die als es Git gab neu angefangen?

Zitat:

Zitat von Namenloser (Beitrag 1352881)

Wenn deine SSD so klein ist, dann hast du mein Mitleid.

Nein, brauchst du nicht. Sie ist natürlich größer, aber deutlich endlich. Es ist ja nicht nur der Teil der aus der Versionsverwaltung kommt. Da liegt, wenn man eine Arbeitskopie benutzt, ja noch mehr drin. Um mal par Zahlen zu nennen: meine aktuelle Arbeitskopie hat ohne Temp-Verzeichnisse (dort lieg aber auch nur Müll) und die erstellten Setups 9,1GB, neu ausgecheckt 4,5GB und die Repos auf dem Server 1,1GB. Wirklich hilfreich sind die Zahlen jetzt nicht, da es sehr viele große Externals aus dem Internet dabei sind.

Zitat:

Zitat von Namenloser (Beitrag 1352881)

Nervig ist es höchstens, wenn man sehr langsames Internet oder eine Volumenbeschränkung hat.

Um die Zeit für das erste Auschecken und das dafür benötigte Datenvolumen geht es mir nicht.

Zitat:

Zitat von Namenloser (Beitrag 1352881)

Allerdings gibt es zur Not auch Shallow Clones, mit denen man nicht die gesamte Historie laden muss. Somit gilt das Argument eigentlich also doch nicht.

Das kannte ich nicht. Ist wohl zwischen den vielen Konsolenbildchen untergegangen. Ach und deswegen ist das Auschecken bei Git so kompliziert. Muss ich mal googlen. Bei einigem aus dem Internet braucht man die Historie nicht.

Zitat:

Zitat von Namenloser (Beitrag 1352881)

Ich finde außerdem, der Vorteil, auf die komplette Historie Zugriff zu haben und jederzeit committen zu können, auch wenn den Server down ist oder man keine Internetverbindung hat, überwiegt diesen kleinen Nachteil, selbst wenn es denn einer wäre, bei weitem.

Ja, ich schlucke ja diese bitter Pille auch, wenn andere es akzeptieren, dass es ein Nachteil ist und dies fleißig bei ihren Empfehlungen mitteilen. Heißt ja nicht, das man nicht mit einem Nachteil leben kann.

Zitat:

Zitat von Uwe Raabe (Beitrag 1352883)

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.

Stimmt wohl nicht. Habe gerade mal nachgeschaut. Jcl mit Git ausgecheckt ist ca. 1,5 mal so groß wie mit SVN ausgecheckt (jeweils mit Standarteinstellungen, soweit ich da keinen Fehler gemacht habe). Mercurial kann ich natürlich nicht beurteilen. Darum ging es mir auch nicht.

Zitat:

Zitat von mse1 (Beitrag 1352880)

Zitat:

Zitat von einbeliebigername (Beitrag 1352876)

Also Anlaufstelle bleibt das Repository. Dort muss immer anhand der Versionsnummer der Sourcecode gefunden werden können. Bei SVN kein Problem, dort hat man quasi aus der Versionsnummer heraus einen direkten Link auf den Sourcecode.

Das ist bei Git nicht anders. Die Versionsnummern sind einfach etwas länger. ;-)
Das Kommando wäre "git checkout <VERSIONSNUMMER>". Man muss von der Versionsnummer lediglich soviel Zeichen angeben, bis sie im Repository eindeutig ist.

Bei Git wird nach meinem Kenntnisstand für die von dir erwähnte Nummer ein Hash-Algorithmus benutzt. Ich kenne jetzt nicht den Genauen Wert, aber denke der wirft 128 Bit raus. Wie viel von diesen Bits muss ich heute angeben, damit der noch in 10, 20 Jahren sicher eindeutig ist? Richtig alle! Auch bekommt man diese Nummer nicht in die Versionsinformationen der Exe, welche von Windows standardmäßig angezeigt wird. Und dann erkläre mal bitte einem Kunden, das heute eine kleinere Zahl neuer bedeutet und morgen eine Größere. Wünsche dir dabei viel Spaß. Ich persönlich kann die Ausgaben von Hash-Algorithmen nicht mal am Telefon fehlerfrei nebenbei rüberbringen, geschweige denn mir merken. Und das soll ein Kunde können. Niemals. Manche kommen ja teilweise schon bei vierstelligen Zahlen durcheinander.

AW: Subversion und VisualSVN für Ein-Mann-Entwicklung

Zitat:

Zitat von einbeliebigername (Beitrag 1352941)

Und da meine ich im Falle Git dieses alles ist eine Datei-Konzept (müsste heut alles ist ein Objekt sein)

Also ich habe im Repository Dateien liegen, keine Objekte. Wie du das meinst, kann ich gerade nicht nachvollziehen. :stupid:

Zitat:

Zitat von einbeliebigername (Beitrag 1352941)

und dieses Konsolenlastige. Ich habe doch keinen Monitor mit Millionen von Pixeln, welche bald Milliarden verschiedener Farben anzeigen können, um mich dann wieder mit Textoutput rumschlagen zu müssen.

Sowohl bei SVN als auch bei Git gibt es ein Konsoleninterface und diverse GUIs. Ohne eine GUI wie TortoiseSVN ist SVN genauso konsolenbasiert.
Der Unterschied ist nur, dass du bei SVN deutlich weniger Funktionen hast, so dass die GUIs diese gut abdecken können, während bei Git viele zusätzlichen (!) Funktionen nicht über die GUI funktionieren, weil es einfach zu viele sind.

Beispiel commit, das es ja bei beiden gibt, wenn auch mit anderen Auswirkungen:
SVN:

Zitat:

svn commit
--changelist ARG
--depth ARG
--editor-cmd ARG
--encoding ENC
--file (-F) FILE
--force-log
--keep-changelists
--message (-m) TEXT
--no-unlock
--quiet (-q)
--targets FILENAME
--with-revprop ARG

Git:

Zitat:

AW: Subversion und VisualSVN für Ein-Mann-Entwicklung

Zitat:

Zitat von einbeliebigername (Beitrag 1352941)

Zitat:

Zitat von mse1 (Beitrag 1352880)

Dann kann ich dir "git tag <DEINE-VERSIONSNUMMER> <VERSIONS-SHA>" empfehlen. Dadurch wird die Versions-SHA des entsprechenden Snapshots mit deiner Versionsnummer verbunden. Der Zugriff auf die entsprechenden Dateien geschieht dann mit:
"git checkout <DEINE-VERSIONSNUMMER>".
In MSEgit geht das Anlegen eines Tag auch mit RightClick-'Tag' in der entsprechenden Zeile des Commit-Log.

AW: Subversion und VisualSVN für Ein-Mann-Entwicklung

Zitat:

Zitat von Harry Stahl (Beitrag 1352702)

Gibt es Fans von Mercurial, was ja auch in Delphi 10.1 integriert ist?

Ja, gibt es. Und ich würde es uneingeschränkt empfehlen. Zusammen mit

TortoiseHg. Und falls du jemals deine Repositories online bereitstellen willst, bietet sich Bitbucket an.

Wenn du des Englischen mächtig bist empfehle ich noch die Lektüre von

VCBE und

hginit.com. Wobei ersteres auch für Freunde von Git interessant sein könnte.

Mercurial ist wie Git aber in benutzerfreundlich. Ich benutze notgedrungen auch immer wieder Git und das schon seit Jahren, konnte mich aber trotz der Lektüre zweier Bücher und zweier mehrstündiger Videokurse (von O'Reilly) nicht damit anfreunden. Seltsam, denn bei Mercurial ging das Lernen viel intuitiver vonstatten und mithilfe des entsprechenden Buches von O'Reilly ging auch der Einstieg in die fortgeschrittenen Themen einfach und schnell.

Will heißen, es handelt sich nicht um ein Vorurteil in Sachen Git.

So, und wer hier Git immer noch vorzieht kann mit jetzt erklären wie benutzerunfreundlich ein Kommandozeilenwerkzeug denn bitte sein kann, welches, wenn ich es um Hilfe bitte, anstatt mir eine Kurzhilfe anzuzeigen wie das bei --help nunmal gang und gäbe ist, mir auf Windows nen Browser mit dem Handbuch öffnet? Ernsthaft? Und abgesehen davon braucht man zur Lektüre des Handbuchs als Einsteiger noch ein Fachwörterbuch Git. Wenn man sich schon mit dezentralisierter Versionskontrolle auskennt, mag es nicht ganz so schlimm sein.

Git, der wichtigste Hinweis steckt eigentlich schon im Namen.

Git ist ein zusammengefrickeltes Konglomerat von (Unix-)Shellskripten und kompilierten Programmen, was auf unixoiden Systemen auch hervorragend funktioniert. Für Windows wurden dann Brücken geschlagen, die auch halbwegs funktionieren. Mercurial ist eine Versionskontrolle mit Architektur und Design, die Dank Python, auf allen Systemen auf denen Python läuft auch gleich gut läuft.

So, viel Erfolg bei der Entscheidungsfindung.

Falls du jemals deine Entscheidung bereust, nimmste

reposurgeon zum verlustfreien Konvertieren mit chirurgischer Kontrolle (um mögliche alte Narben in der Versionshistorie auszubügeln).

Nachtrag:
Subversion wird bei größeren Projekten gern mal a****langsam. Außerdem kannste dir zwar alle Zweige und so weiter auschecken, hast dann aber ein vielfaches der Größe des SVN-Repos (Größe auf dem Server) bei dir rumliegen. Eine Konvertierung von SVN auf Mercurial oder Git spart meiner Erfahrung nach 80% Platz ein. Und das ist für das Repo selbst. Also auf dem SVN Server > 30 GiB und als Mercurial Repo (ohne etwas rauszuwerfen) ~ 6 GiB. Besagtes Repo als Arbeitskopie wiegt bei SVN mal gut über 100 GiB. Kommt natürlich einfach auf die Menge der Zweige und Tags an.

Bei Subversion ist aus meiner Sicht das schlimmste die Vermischung des Konzepts der Zweige und Tags mit dem von Pfadnamen. Bazaar hat das zum Teil auch kopiert. Auch sind Tags nur entsprechend der üblichen Konvention Tags. Prinzipiell hält dich niemand davon ab in einen Tag eine Änderung einzuchecken. Es sei denn der Admin war clever und hat diese Pfade mit irgendwelchen Hookskripten geschützt (was aber leider auch nicht trivial ist).

AW: Subversion und VisualSVN für Ein-Mann-Entwicklung

Vielen Dank für die weiteren Hinweise.

Habe jetzt eine Menge Informationen erhalten, die mir und im Zweifelsfalle auch anderen helfen.

Werde nun neben Subversion auch GIT und Mercurial einrichten und beide Systeme testen.
Wollte gerade mit Mercurial anfangen. Client soweit klar (Tortoise HG, da auch für MAC und Linux verfügbar), ist auch schon geladen und installiert.

Welches Serverprogramm (Windows - möglichst mit Grafischer Oberfläche) würdet Ihr hier für Mercurial empfehlen?

Ich gehe mal davon aus, dass es kein Problem sein wird, auf meinem Web-Server mehrere SVN-Systeme laufen zu lassen, oder sind da Schwierigkeiten zu erwarten?

AW: Subversion und VisualSVN für Ein-Mann-Entwicklung

Zitat:

Zitat von Harry Stahl (Beitrag 1353017)

Ich gehe mal davon aus, dass es kein Problem sein wird, auf meinem Web-Server mehrere SVN-Systeme laufen zu lassen, oder sind da Schwierigkeiten zu erwarten?

IM normal Fall sollte das kein Problem sein. Aber aus meiner Erfahrung heraus ist eine Linux Rechner/Server die bessere Wahl um die ganzen SVN-Systeme zu testen, da hier die Installation viel einfach von der Hand geht als bei Windows. So war zumindest mein Empfinden.