Hallo zusammen,

ich stehe grade vor der Frage, für welches Versionskontrollsystem ich mich entscheiden soll. Ich hab mehrere kleine/mittlere Projekte, die ich nebenbei entwickle. Bis jetzt hab ich das ohne History auf der Platte gemacht, doch das wird auf Dauer zu anstrengend mit Sync zum Laptop usw. Ich hab auf meinem Server mal SVN und Git eingereichtet und mit beidem rumgespielt (mit Plugin in Eclipse, bzw. TortoiseSVN/Git) - tun auch das, was sie sollen.

Jetzt interessieren mich aber die Unterschiede und welches sinnvoller für mich ist. SVN ist ja nur zentral organisiert, Git genau das Gegenteil. Was hat jetzt zentral/dezentral für nen Vorteil (hab ich immer noch nicht so ganz kapiert, weil es von der Bedienung für mich fast gleich ist - ok, in Git muss ich nocheinmal 'Push' drücken)? Was nutzt/bevorzugt ihr?

An der Uni nutzen wir für unser Softwareprojekt CVS, was ich aber irgendwie nicht so toll finde - daher hab ich das mal für privat ausgeschlossen. Gibt es da noch ein System, was man sich mal anschauen müsste?


Freu mich über Anregungen und Tipps,

Webo

Ganz klar: Git. Allerdings nicht in dieser Tortoise-Version, sondern nur auf der Konsole. Vorteil: Klein, übersichtlich, einfache und wenige Befehle, überschaubare Funktionen, trotzdem leistungsstark.

Git beweist genau dann seine Stärken, wenn man dem Gegenüber nicht traut oder nicht ständig eine Verbindung zu anderen Mitarbeitern oder seinem Server besitzt. Der Unterschied besteht etwas in der Philosophie der Projekte:

1. CVS (Completely Volatile Shit): zentrale Einzeldatei-Verwaltung
2. SVN (Sowas von Nutzlos): Zentrale Dateiarchiv-Verwaltung
3. Git (igitt, AKA 'git'): Dezentrale Patch-Verwaltung
4. Hg (AKA Quecksilber): Dezentrale Patchset-Verwaltung
5. Bzr (Das Teil zum Einkaufen): Dezentrale Feature-Verwaltung

Sprich bei Git verwaltet man weniger den Stand einzelner Dateien oder Ordner, sondern vielmehr eine Reihe von Patches, die ein Feature beschreiben, bzw. die Anleitung, um aus diesen Anleitungen etwas Fertiges zu bauen. Git ist dabei in Bezug auf die Abstraktion in der Mitte zwischen Einzeldateien und Feature-Verwaltung. Kurz gesagt: Bei Bazar verwaltest Du nur noch Patch-Sets und deren Abhängigkeiten, die (wenn jeder Patch immer zu einer lauffähigen Version führt) es einem Erlauben, jedes Einzelne implementierte Feature einer Anwendung einzeln ein- und auszuschalten. Für ähnliche Ergebnisse müsste man bei Git jedes Feature unabhängig auf einen Branch legen und dann selektiv alle Branches einzeln zusammenführen.

Im Endeffekt ist halt die Frage, wie deine Vorgehensweise beim Entwickeln ist. I.a.R. ist aber Git für die meisten Einsatzzwecke optimal.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Hi,

kommt darauf an... privat zu hause nutze ich svn - da ich allein auf die Sourcen zugreife und der SVN-Server auf meinem Homeserver läuft habe ich damit nicht nur eine Versionierung sondern automatisch ein erstes Backup, da die Sourcen neben der Entwicklungsmaschine auch auf dem Server liegen.

Bei dezentralen Systemen geht das auch, dann sind aber immer mind. 2 commits oder pushes notwendig - das geht mit mir SVN wesentlich einfacher.

Wenn ich mit anderen zusammenarbeiten müsste, dann klar Mercurial oder git.

Auf der Arbeit nutzen wir TC (Team Coherence). äh ja.. ich sag besser nichts...

Grüße

Webo hat folgendes geschrieben :

Jetzt interessieren mich aber die Unterschiede und welches sinnvoller für mich ist. SVN ist ja nur zentral organisiert, Git genau das Gegenteil. Was hat jetzt zentral/dezentral für nen Vorteil (hab ich immer noch nicht so ganz kapiert, weil es von der Bedienung für mich fast gleich ist - ok, in Git muss ich nocheinmal 'Push' drücken)? Was nutzt/bevorzugt ihr? An der Uni nutzen wir für unser Softwareprojekt CVS, was ich aber irgendwie nicht so toll finde - daher hab ich das mal für privat ausgeschlossen. Gibt es da noch ein System, was man sich mal anschauen müsste?

• CVS ist einfach nicht mehr up to date. SVN kann alles, was CVS kann, und mehr.
  
• SVN benutze ich seit Jahren, sowohl beruflich als auch privat in Form von TortoiseSVN und seltener auch auf der Kommandozeile unter Linux. Man kann es uebrigens auch ohne Server betreiben, indem man das Repository einfach in einem Verzeichnis auf der lokalen Platte anlegt. Ich bin damit recht zufrieden, wenn auch das Branching+Merging deutlich besser sein koennte.
  
• Zu GIT kann ich nicht viel sagen. Ich habe mehrfach den Ansatz gemacht, es auszuprobieren. Ich fand es immer zu kompliziert, aber vielleicht bin ich auch zu bloed. TortoiseGit habe ich mir noch nicht angesehen, sollte ich aber vielleicht mal.
  

Edit:
Ach ja, Du wolltest den Unterschied zwischen zentral und verteilt wissen:
Zentral heisst, es gibt genau einen Server, auf dem das Repository abgelegt ist, mit allen Branches und tags. Jeglicher Austausch geht ueber diesen Server. Verteilte Systeme funktionieren ohne zentralen Server, im Falle von GIT ist jede Working Copy ein eigener Branch, mit dem man nach Herzenslust rumspieln kann. Man kann auch davon wieder neue Working Copies anlegen und dazwischen immer wieder mal mergen oder Patches austauschen. Natuerlich kann man auch mit GIT irgendwo ein zentrales Repository anlegen, in das dann alle Aenderungen wieder zurueckfliessen. Es ist damit sehr flexibel aber IMHO verliert man auch gerne mal den Ueberblick. Andere verteilte SCMs sind Bazaar, BitKeeper und Mercurial.

twm

git extensions, wenn man auf einer windows kiste arbeitet. nett gemacht und einfach zu bedienen. bindet sich auch in visual studio ein.

für lazarus gibt es auch ein plugin, welches aber noch nicht ganz fertig ist.

git oder mercurial finde ich gut. svn kann ich mich persönlich nicht wirklich mit anfreunden, obwohl ich es für manche auftraggeber nutzen muss.

Tankard hat folgendes geschrieben :

svn kann ich mich persönlich nicht wirklich mit anfreunden, obwohl ich es für manche auftraggeber nutzen muss.

Gut, dass Git für diese Zwecke SVN Support anbietet, so kann man bei seinen bekannten Befehlen bleiben und muss sich nicht umstellen.

Ich wollte vor einer Weile mal einen Git oder Mercurial Server testweise aufsetzen, aber ich habe kaum Informationen dazu gefunden. Überall ging es nur um dezentrale Sachen, aber nicht um einen fest installierten Dienst auf einem fest definierten Server.
Zusätzlich auch dezentral arbeiten zu können, fände ich schon gut, aber ein stabiler Windows-Dienst auf einem Windows Server ist in meinem Fall eine Grundvoraussetzung. Gefunden habe ich zwar Bastellösungen wie auf cygwin basierende Server oder ähnliches, dazu dann Anleitungen, die einen Weg empfehlen und andere Anleitungen, die den Weg für schlecht halten.

Deshalb bin ich dann sowohl privat als auch beruflich wieder bei SVN gelandet und teste da gerade verschiedene Lösungen wie den VisualSVN Server im Zusammenspiel mit dem in Delphi integrierten SVN-Client.

Tankard hat folgendes geschrieben :

für lazarus gibt es auch ein plugin, welches aber noch nicht ganz fertig ist.

Wie heißt den das?
Klingt ja Interessant!

jaenicke: Einfachstenfalls reicht ein schreibbares Verzeichnis auf einer Freigabe. Hat dann nicht alle Features (commit hooks fehlen), aber wenn man unbedingt will, geht das.
Auf Linux ist das einfacher, da ist ein git-Server ne Sache von ein paar Minuten. Alternativ gibts genug Dienste, die sowas "in der Wolke" machen... github ist mein Favorit, was Features angeht. Und für Firmen auch recht günstig.

GUI-mäßig bin ich nach Experimenten mit git extensions und TortoiseGit immer wieder auf der Kommandozeilie gelandet. "git push origin" tippe ich schneller, als ich in diesen seltsamen Menüs was finde Zum committen dann allerdings das mitgelieferte "git gui", um Hunk-Weise Commits zusammenzubauen ist das immer noch das Schönste. Kann übrigens kein anderes GUI.

Die git-svn Bridge sollte man nicht wirklich erwähnen, jedenfalls unter Windows unbrauchbar, da Windows nicht so schnell CreateProcess'en wie Linux forken kann. Und das Ding will einige hundert Forks/Sekunde machen.


Subversion kann ich nicht ausstehen, aber muss das für die Ecke verwenden Ist mir einfach zu langsam. Außerdem braucht es für jede Aktion eine Netzwerkverbindung, und meine ist einfach zu langsam. Im LAN geht das, aber WAN eher nicht.
Auch wichtig: SVN kann keine Feature Branches. Wenn ich in Git ausprobieren will, ob ein Ansatz funktioniert, mach ich einfach einen Branch auf. Wenns klappt, merge. Wenn nicht, dann kann ich den einfach ignorieren oder löschen.
Um das gleiche in SVN zu machen, muss man echt Zeit mitbringen. Und dann klappt das Mergen nie (Konflikte ohne Ende), was Git automatisch auflösen kann.


Um wieder auf die Original-Frage zu kommen:

Webo hat folgendes geschrieben :

Ich hab mehrere kleine/mittlere Projekte, die ich nebenbei entwickle. Bis jetzt hab ich das ohne History auf der Platte gemacht, doch das wird auf Dauer zu anstrengend mit Sync zum Laptop usw.

-> Du willst git und zwischen den beiden Rechnern per push/pull hin und her synchronisieren. Wenns mehr Rechner werden, kann das unhandlich werden, da lohnt sich dann ein Server.

Danke für die vielen Antworten - ich werde wohl erstmal bei Git bleiben.

Martok hat folgendes geschrieben :

Auch wichtig: SVN kann keine Feature Branches. Wenn ich in Git ausprobieren will, ob ein Ansatz funktioniert, mach ich einfach einen Branch auf. Wenns klappt, merge. Wenn nicht, dann kann ich den einfach ignorieren oder löschen. Um das gleiche in SVN zu machen, muss man echt Zeit mitbringen. Und dann klappt das Mergen nie (Konflikte ohne Ende), was Git automatisch auflösen kann.

Auch ein interessanter Punkt, der bei mir bis jetzt aber noch nicht ins Gewicht gefallen ist - aber gut zu wissen.

Was noch erwähnt werden sollte: Mit bitbucket.org/ gibt es seit kurzem endlich auch für git einen Anbieter kostenloser privater Repos. Für Mercurial, welches oft als das Windows-freundlichere DVCS bezeichnet wird, natürlich schon länger, aber ich kann nur für git sprechen.

Wobei das für mich nur für Open Source Projekte in Frage kommt, eigene Closed Source Projekte oder gar berufliche Projekte würde ich / würden wir niemals bei einem fremden Hoster lagern wollen. Schließlich sind die Quelltexte wichtiges Kapital.

jaenicke hat folgendes geschrieben :

Wobei das für mich nur für Open Source Projekte in Frage kommt, eigene Closed Source Projekte oder gar berufliche Projekte würde ich / würden wir niemals bei einem fremden Hoster lagern wollen. Schließlich sind die Quelltexte wichtiges Kapital.

Und damit, dass die nicht "abhanden kommen" verdienen die ihr Geld. Wenn da was passiert, sind die ganz schnell weg vom Fenster; grade beim Code Hosting gibts Konkurrenz ohne Ende, da reicht schon das Gerücht dass der Code nicht sicher ist.

Wenn du willst, darfst du aber gerne GitHub FI kaufen, "starting at $5,000 per year". Hab schon Geld sinnloser aus dem Fenster geworfen gesehen. Hat man z.B. wieder drin, wenn man nur jedes zweite Delphi-Update kauft

Muss man halt abwägen, für Top Secret-Projekte ist das sicher noch anders als "normale" Aufträge.

Martok hat folgendes geschrieben :

Und damit, dass die nicht "abhanden kommen" verdienen die ihr Geld. Wenn da was passiert, sind die ganz schnell weg vom Fenster

Das nutzt dir dann am Ende aber auch nix.

Martok hat folgendes geschrieben :

Wenn du willst, darfst du aber gerne GitHub FI kaufen, "starting at $5,000 per year". Hab schon Geld sinnloser aus dem Fenster geworfen gesehen.

Bisher läuft es mit CVS auch gut und selbst durch einen SSH-Tunnel über eine eher schlechte UMTS-Verbindung (max 2 MBit, meistens deutlich weniger) relativ schnell. Ähnlich sieht es mit SVN aus, das aber gegenüber CVS natürlich einige Vorteile hat. Und das ist kostenlos.

Ich habe mittlerweile aber versucht einen älteren PC mit Debian und einem Mercurial-Server auszustatten, aber leider läuft das bisher alles andere als stabil. (Sprich, Debian ist jetzt schon zum vierten Mal mit ner Kernel Panic wegen ner fatalen Exception abgestürzt und wenns dann mal läuft bricht die Verbindung bei größeren Dateien immer wieder ab. Im lokalen Netz wohlgemerkt. ) Naja, mal auf ner VM unter kontrollierten Bedingungen ausprobieren...