Subversion und VisualSVN für Ein-Mann-Entwicklung

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

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.

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

[einbeliebigername]

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.

[jaenicke]

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:

git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
[--dry-run] [(-c | -C | --fixup | --squash) <commit>]
[-F <file> | -m <msg>] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author=<author>]
[--date=<date>] [--cleanup=<mode>] [--[no-]status]
[-i | -o] [-S[<keyid>]] [--] [<file>…​]

[mse1]

Zitat:

Zitat von einbeliebigername (Beitrag 1352941)

Zitat:

Zitat von mse1 (Beitrag 1352880)

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.

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.

[Assarbad]

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

[Harry Stahl]

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?

[RWarnecke]

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.

[Harry Stahl]

Zitat:

Zitat von RWarnecke (Beitrag 1353022)

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.

Kann sein, mein Webserver ist aber ein Windows 2012 R2 Server und da kann ich erst mal nichts dran ändern (gemietetes Paket).

[himitsu]

Zitat:

Zitat von RWarnecke (Beitrag 1353022)

So war zumindest mein Empfinden.

Also GIT auf Android zu installiern war sowas von einfach, da hält Linux bestimmt nicht mit und es hat sogar 'nen graphisches GUI UI.

App im Store suchen, installieren klicken, 'ne Sekunde warten, starten und dann nur noch Benutzer und das Repo einrichten.
Subversion läuft leider nur überall da, wo man z.B. VisualSVN installieren kann (also im Windows) und zur Nutzung des Apache-SVN muß halt ein Apache laufen (den Apache gibt es für fast alle Systeme, nur nicht für Android oder iPhone)


So gesehn ist das Handy auch eine witzige Angelegenheit, für 'ne Verionsverwaltung ... immer und überall dabei, auch wenn kein Internet verfügbar, und dennoch getrennt vom PC/Schlepptop, falls der mal kaputt geht.

[Lemmy]

falls hier jemand eine Möglichkeit besitzt virtuelle Maschinen einzubinden (z.B. ESXI) und eine fertige Lösung aus bugtracking und SCM braucht und nicht den "harten" Weg gehen will: https://www.turnkeylinux.org/redmine
Redmine finde ich inzwischen ganz gut, mit integriert auch ein Wiki für die Dokumentation und als SCM steht SVN, Git, Mercurial und Bazaar zur Verfügung, incl. Integration ins Bugtracking (also Zuweisung von Commits zu Bugs)

Das Ding nutze ich für so ziemlich alle meine Projekte

[samso]

Zitat:

Zitat von Harry Stahl (Beitrag 1353017)

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

Bei Mecurial brauchst Du für den Hausgebrauch keinen Server. Das Ganze arbeitet Dateibasiert. Du könntest also z.B. einen USB-Stick zu Deinem "Server" erklären und immer auf den Stick pushen.

[dummzeuch]

Zitat:

Zitat von samso (Beitrag 1353033)

Zitat:

Zitat von Harry Stahl (Beitrag 1353017)

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

Bei Mecurial brauchst Du für den Hausgebrauch keinen Server. Das Ganze arbeitet Dateibasiert. Du könntest also z.B. einen USB-Stick zu Deinem "Server" erklären und immer auf den Stick pushen.

Dasselbe geht uebrigens auch mit SVN. Das Repository kann auch einfach ein Verzeichnis sein. Mit Tortoise-SVN ist das auch im Nu angelegt.

[dummzeuch]

Zitat:

Zitat von Lemmy (Beitrag 1353032)

falls hier jemand eine Möglichkeit besitzt virtuelle Maschinen einzubinden (z.B. ESXI) und eine fertige Lösung aus bugtracking und SCM braucht und nicht den "harten" Weg gehen will: https://www.turnkeylinux.org/redmine
Redmine finde ich inzwischen ganz gut, mit integriert auch ein Wiki für die Dokumentation und als SCM steht SVN, Git, Mercurial und Bazaar zur Verfügung, incl. Integration ins Bugtracking (also Zuweisung von Commits zu Bugs)

Danke fuer den Hinweis, das werde ich mir gleich mal genauer ansehen. Allerdings hat sich ein Wiki auf der Arbeit bei keinem meiner bisherigen Arbeitgeber durchsetzen koennen.... Alle wollten lieber Word-Dokumente. Verstanden habe ich das nie.

[Lemmy]

Zitat:

Zitat von dummzeuch (Beitrag 1353040)

Danke fuer den Hinweis, das werde ich mir gleich mal genauer ansehen. Allerdings hat sich ein Wiki auf der Arbeit bei keinem meiner bisherigen Arbeitgeber durchsetzen koennen.... Alle wollten lieber Word-Dokumente. Verstanden habe ich das nie.

Kann ich auch nicht verstehen. Da ich inzwischen aber meine Dokumentation insbesondere für die Supportmitarbeiter nur noch im Wiki schreibe, müssen die zwangsläufig da rein schauen bzw. wenn sie es nicht machen und mich fragen bekommen die den entsprechenden Link :-)

[Assarbad]

Zitat:

Zitat von Harry Stahl (Beitrag 1353017)

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

Sowohl Mercurial als auch Git kommen mit eingebautem Server. Git spricht auch noch sein eigenes Protokoll, welches effizienter ist als wenn du es als Webserver laufen läßt (rein technisch ist das bei Mercurial ähnlich, dort passiert das mit Bundles). Von der Sache her das gleiche Protokoll welches über SSH (dann allerdings via stdout/stdin) gesprochen wird.

Auch können beide über SSH angesprochen werden. Da du dein Repository sowohl mit Mercurial wie auch mit Git vollständig lokal hast, macht es eigentlich wenig Sinn sich da extra einen Server aufzusetzen um eine grafische Oberfläche zu bekommen. Denn die Oberfläche hast du ja mit TortoiseHg respektive TortoiseGit bereits. Git GUI ist bei Git for Windows dabei und ansonsten gibt es noch SourceTree als kostenlose aber nicht quelloffene Alternative.

Als Weboberfläche ginge für beide Phabricator oder Kallithea, nur für Git gibt es noch weitere wie bspw. cgit, Klaus, GitLab und einige andere Weboberflächen die du mit gängigen Webservern (Nginx, Apache) laufenlassen kannst (teils wird auch noch PHP oder Python usw. benötigt). Im Grunde hängt es davon ab was du erreichen willst (bspw. ob du Benutzerkonten brauchst usw.). Redmine, welches Lemmy empfahl, kann ich auch nur wärmstens empfehlen, so man sich mit der Wiki-Syntax abfinden kann (die ich etwas gewöhnungsbedürftig fand).

Windows kann ich nun aber wirklich nicht als Serversystem empfehlen.

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?

Nein, gibt es keine. Für Apache gibt es da mod_dav_svn und Nginx kann die DAV-HTTP-Methoden durchreichen, falls du es effizienter als Apache möchtest. Das geht sowohl auf Windows wie auch auf einem BSD oder Linux. Wobei letztere effizienter mit den Ressourcen umgehen und daher empfohlen seien.

ViewVC ist eine Oberfläche für CVS und SVN welche mit lokalen Repositories umgehen kann. Benötigt allerdings eine MySQL-Datenbank.

Zitat:

Zitat von Harry Stahl (Beitrag 1353023)

Kann sein, mein Webserver ist aber ein Windows 2012 R2 Server und da kann ich erst mal nichts dran ändern (gemietetes Paket).

Also es gibt eine Menge Anbieter die virtuelle Server schon für kleines Geld anbieten. Und wenn dein Paket auf Hardware läuft, kannste auch einfach nen Linux/BSD-Server als Hyper-V-Gastsystem aufsetzen.

Zitat:

Zitat von dummzeuch (Beitrag 1353039)

Dasselbe geht uebrigens auch mit SVN. Das Repository kann auch einfach ein Verzeichnis sein.

Es ist richtig, daß ein SVN-Repo so initialisiert werden kann - nichts anderes passiert ja serverseitig. Es ist nur gerade nicht dasselbe. Der Unterschied ist eben, daß jeder Klon bei Mercurial und Git ein ganz eigenes (wenn auch mit dem Ursprungsrepo verwandtes) Repo darstellt. Du kannst zwar auch mit svnsync ein SVN-Repository "klonen" wenn du sicherstellst, daß die UUID die gleiche ist wie beim Ursprungsrepo und dann mit "svn switch" zwischen beiden wechseln. Aber versuch mal in beide Repos was einzuchecken (was geht) und dann diese Unterschiede zu mergen. Das geht nämlich nicht. Dein Vergleich hinkt daher fürchterlich.

[jaenicke]

Wir benutzen den Bonobo Git Server mit einem Windows Server.
Das war auch der Grund weshalb wir uns gegen Mercurial entschieden haben: Wir haben schlicht keinen einfach installierbaren und gut wartbaren Serverdienst gefunden.

Bonobo hat einen integrierten Webserver, sprich du kannst deine Repositorys einfach per Weboberfläche anlegen, verwalten usw.

[Harry Stahl]

Noch 2 Fragen:

1. Kann man für die verwendeten Clients (wenn Grafischer Client) eigentlich unterschiedliche unter Windows / MAC / Linux nutzen, oder ist es erforderlich (sinnvoll) einen vom gleichen Hersteller zu nutzen?

2. Was vergleichbares wie den VisualSVN-Server (herrlich leicht zu installieren und zu verstehen) gibt es nicht für GIT und Windows? Bei dem Bonobo-Server müsste man sich erst mal ein wenig durch die Installation kämpfen und als IIS-Server einbinden.

[jfheins]

Du kannst bei den grafischen Clients auch mehrere verschiedene GUIs auf dem selben Computer benutzen. Du bekommst dann schon eine Fehlermeldung, wenn die sich ins Gehege kommen.
Bei SVN heißt die irgendwie "svn working copy locked". Bei git bekommst du

Zitat:

fatal: Unable to create 'v:/path/to/files/.git/index.lock': File exists.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.

Auf einem anderen Rechner kannst/musst du dann eh andere Clients einsetzen. SourceTree gibt es bspw. nicht für Linux. TortoiseGit gibt's nicht für macOS.

[Assarbad]

Zitat:

Zitat von Harry Stahl (Beitrag 1353059)

1. Kann man für die verwendeten Clients (wenn Grafischer Client) eigentlich unterschiedliche unter Windows / MAC / Linux nutzen, oder ist es erforderlich (sinnvoll) einen vom gleichen Hersteller zu nutzen?

Kannst von der Sache her beliebige Clients benutzen. Wenn die Versionen zu weit auseinander sind - aber das muß schon sehr weit auseinander sein - kann es u.U. zu Problemen kommen. Ist aber äußerst unwahrscheinlich, da die Übertragung normalerweise in einer Form stattfindet welche sogar die jeweils ältesten Clients verstehen. Die dort lokal initialisierten Repos haben dann nur möglicherweise nicht alle Features aktiviert. Aber wie gesagt, da müßtest du dir schon aktiv Mühe geben um einen solchen Versionsunterschied künstlich zu erzeugen. Diese Aussage gilt sowohl für Mercurial wie auch für Git.

Zitat:

Zitat von Harry Stahl (Beitrag 1353059)

2. Was vergleichbares wie den VisualSVN-Server (herrlich leicht zu installieren und zu verstehen) gibt es nicht für GIT und Windows?

Git ist jene Versionskontrolle zu der es ernsthaft mehrere verschiedene Wrapper gibt um die Benutzung zu vereinfachen. Mercurial hat und braucht sowas nicht, weil es von Haus aus benutzerfreundlich daherkommt. Wenn du also "herrlich leicht zu installieren und zu verstehen" als Maßstab nimmst, könnte Git unter Umständen die falsche Wahl sein.

Mir ist nichts dergleichen bekannt wie VisualSVN-Server jedoch für Git, aber ich hoste sowas nicht auf Windows. Sicher kann jemand anderes weiterhelfen.

[warschonweg]

Woher kommt eigentlich die irrige Annahme, ausgerechnet unter Windows sei irgendwas komplizierter zu installieren als unter Linux?

[Assarbad]

Zitat:

Zitat von warschonweg (Beitrag 1353064)

Woher kommt eigentlich die irrige Annahme, ausgerechnet unter Windows sei irgendwas komplizierter zu installieren als unter Linux?

Keine Ahnung, wer hat denn das so behauptet? Ein Zitat könnte helfen.

Übrigens war dies mit Git einst der Fall; also daß es komplizierter zu installieren war. Git for Windows gibt es noch nicht so lange. Das alternative Vorgängerprojekt mußtest du selbst lokal kompilieren und zwar ohne dafür eine code-signierte Basis (sprich Compiler) nehmen zu können. Das Resultat war mit etwas Glück Git als Kommandozeilenversion und mehrere Gigabyte Objektdateien. Juhu! Das war aber auch bevor libgit2 eingeführt wurde, wenn ich mich recht entsinne. Seit es das gibt, sprießen die Clients ja wie die Pilze aus dem Boden (inklusive Visual Studio etc). Und Git for Windows sehe ich allein aufgrund der Signaturen als Riesenfortschritt an.

Ansonsten ist Windows vor allem anders und in Sachen Netzwerkstack gegenüber BSD oder Linux durchaus benachteiligt. Aber man kann sich das auch schönreden. Hab ich schließlich auch gemacht, als ich noch aktiv Windows-Domänenadministrator war :mrgreen: ... einfach Apache draufgeklatscht damals und so getan als ob damit alles in Butter wäre. Lief auch, nur eben nicht so schnell wie auf Linux oder eben FreeBSD.

Aber auch auf der Unixseite habe ich schon einige hartgesottene Adminurgesteine kennenlernen dürfen, die sich an einen schnellen und effizienten Webserver ala Nginx oder Lighttpd nicht gewöhnen können und deshalb bei Apache blieben, oder nicht wußten auf welchem OSI-Layer OpenVPN operiert und deshalb meinten man könne damit keinen Tunnel buddeln, bis ich ihnen das Gegenteil bewies (es ging um die Verbindung zwischen zwei Firmensitzen).

[bra]

Zitat:

Zitat von warschonweg (Beitrag 1353064)

Woher kommt eigentlich die irrige Annahme, ausgerechnet unter Windows sei irgendwas komplizierter zu installieren als unter Linux?

Das ist bei Programmen, die ursprünglich von Linux kommen, gar nicht so ungewöhnlich - da müssen teilweise erst dutzende sonstige Programme (Perl, Apache usw.) installiert und konfiguriert werden.

[Sherlock]

Fairerweise muss man sagen, daß da alles unter Unixen nur darum so einfach ist, weil es in der Regel schon installiert ist, und sich viele kluge Köpfe Gedanken zu Standardinstallationen gemacht haben. Wenn man aus diesen wirklich guten Standards ausbrechen möchte kann es schon mal haarig werden.

Dennoch habe ich nur Unix-Server, weil sie einfach so leicht zu administrieren sind. Wer KlickiBunti für einfach hält, hat noch nicht wirklich administriert. Auch unter echten Windows Servern ist die Konsole optimal. Nicht umsonst hat MS sehr viel Zeit und Energie in die Powershell gesteckt.

Sherlock

[Aviator]

Zitat:

Zitat von Sherlock (Beitrag 1353091)

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

Haha. Das ist wohl wahr. :thumb:

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:

Zitat von Aviator (Beitrag 1353140)

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:

Zitat von jaenicke (Beitrag 1353177)

Zitat:

Zitat von Aviator (Beitrag 1353140)

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:

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: