Brauche Vorschlag für neue Versionsverwaltung [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : Brauche Vorschlag für neue Versionsverwaltung

minos5000

2012-09-24, 11:20:16

Hallo zusammen,

momentan setzen wir bei uns auf der Arbeit Visual Source Safe 6.0 als Versionsverwaltung ein, welche allerdings nicht mehr ohne weiteres unter Win7 läuft. Daher soll nun etwas neues her.

Mein erster Gedanke war SVN, die Krux daran ist aber, dass Änderungen an Dateien in einem Branch nicht automatisch in andere Branches übernommen werden und man alles per Hand mergen muss. Das würde für uns einen sehr große Aufwand bedeuten und die Vorteile von SVN mehr als nichtig machen.

Die einzige mit bekannte Alternative, die nach dem gleichen Prinzip funktioniert wäre der MS Team Foundation Server, aber der wäre für unser kleines Team auch schon wieder Overkill.

Daher meine Frage in die Runde, ob es andere praktikable Alternativen gibt.

Ciao
minos

Gandharva

2012-09-24, 11:22:59

Git, Mercurial oder Bazaar. Alles andere ist Gestern.

/edit
Hier noch was für die Migration: http://code.google.com/p/vss2git/

Monger

2012-09-24, 11:35:37

Git ist an sich toll, nur das Tooling dafür ist für meinen Geschmack immer noch arg dünn, vorallem für Windows. Und ich persönlich finde viele der Features alles andere als selbsterklärend. Für Open Source Projekte ist Git perfekt, für Projekte innerhalb einer existierenden Firmen-Infrastruktur... wir hatten uns da schonmal an einem Umstieg versucht, haben es aber erstmal auf Eis gelegt. Gibt einfach viele Kleinigkeiten die noch klemmen.

Subversion hat nach wie vor seine Stärken und Schwächen. Die Bedienung ist ziemlich idiotensicher, der Server ist robust bis zum Umfallen, die gesamte Produktlandschaft außenrum ist riesig.

Der TFS ist vorallem deshalb toll, weil er eben weit mehr ist als nur eine Quellverwaltung. Die hat so ihre Tücken, gerade die Änderungsverfolgung finde ich da in Subversion weit besser. Übrigens hat MS mit VS 2012 da auch die Lizenzbedingungen gelockert, der TFS ist da insgesamt deutlich günstiger. Gibt auch n Cloudservice für TFS für kleine Teams für sehr geringes Geld.

Was du mit automatischem Mergen meinst, würde mich mal interessieren. Ohne qualitative Aussage sollten Branches eigentlich niemals gemerged werden, irgendjemand muss draufschauen. Der TFS verheiratet das ganz klever mit dem Build Prozess, und erlaubt halt auch z.B. Gated Checkins (d.h. erst nach nach einem erfolgreichen Build inklusive Tests).

Was mich irritiert, ist: ihr seid ein kleines Team, der TFS ist euch zu teuer, aber eure Anforderungen ans Mergen gehen weit über das hinaus was die üblichen Quellverwaltungssysteme anbieten? Das ist mindestens mal exotisch.

Shink

2012-09-24, 11:43:25

Da kann man sagen, was man will - Git scheint das SCM der Zukunft zu sein.
Linux und Eclipse sind nun beide auf Git - beide fanden SVN als nicht gut genug und haben sich jahrelang anders beholfen.

Gandharva

2012-09-24, 11:48:21

Was mich irritiert, ist: ihr seid ein kleines Team, der TFS ist euch zu teuer, aber eure Anforderungen ans Mergen gehen weit über das hinaus was die üblichen Quellverwaltungssysteme anbieten? Das ist mindestens mal exotisch.
Finde das absolut nicht exotisch. So läuft das in etwas moderneren Firmen welche nicht auf alten Strukturen verharren ziemlich häufig mitlerweile. Grade dann glänzen dezentrale VCS wie Git im Vergleich zur altbackenen Client/Server Struktur. In einem kleinen/flexiblen Team dürfte die Umstellung an einem Tag erledigt sein.

Ohne qualitative Aussage sollten Branches eigentlich niemals gemerged werden, irgendjemand muss draufschauen.
Das sagt im Prinzip schon alles über das Umfeld aus in dem hier gearbeitet wird. ;) Bitte nicht falsch interpretieren.

P.S. Auch für Windows gibts mittlerweile gute GUIs für GIT: http://www.makeuseof.com/tag/5-windows-git-clients-git-job/

minos5000

2012-09-24, 11:48:32

Monger

2012-09-24, 12:02:24

@Monger
Mit automatischem Mergen meine ich folgendes:

Angenommen ich habe ein Projekt in VSS von dem es verschiedene Branches gibt v01, v02, v03...
Ändere ich eine Datei in v03, so werden die Änderungen automatisch in v02 und v01 übernommen, d.h. in VSS sind Dateien erst einmal über alle Branches hinweg miteinander verbunden, es sei denn die Verbindung wird händisch getrennt.
Wenn eine Datei in allen Branches gleichermaßen geändert werden muss, dann sollte sie eigentlich auf dem Main Branch geändert werden. Branch heißt ja gerade deshalb Branch, weil er sich mit den anderen Zweigen eben NICHT kreuzt.

Das macht auch kein modernes Quellverwaltungssystem was ich kenne anders. Git hat den großen Vorteil, dass man auch mal fix "on the fly" Mini Branches erstellen kann. TFS kennt für diesen Zweck die Shelve Sets.

Wir haben in den letzten zwei, drei Jahren hier so einige Branching Modelle durchgehechelt. Nach dem Umstieg auf TFS haben sich erstmal alle Entwickler gefreut dass sie problemlos Branches aufmachen können, mittlerweile rudert man da ganz deutlich zurück. Nicht weil das System das nicht mitmacht, sondern weil keiner mehr durchblickt welche Änderung wo wann zu welchem Zeitpunkt aufschlägt.

Grundsätzlich mal: wenn man die selben Änderungen häufiger auf verschiedenen Branchen einspielt, ist mit hoher Wahrscheinlichkeit das Branching Modell falsch.

PatkIllA

2012-09-24, 12:28:27

Branches kann man bei SVN doch auch problemlos aufmachen.

Mich stört bei SVN, dass man nicht wirklich umbenennen und verschieben kann. Da hat man dann ruckzuck assige Tree-Konflikte die man nur mühsam wieder begeben kann.
Ist das bei den verteilten Systemen besser?

Bei den verteilten Versionsverwaltungen hätte ich bedenken, dass viele zu lange bei sich lokal arbeiten und es dann nicht mehr zurückbekommt oder der Rechner abraucht.
Wir müssen den Leuten jedenfalls auch regelmäßig auf die Finger schauen, dass die nicht wochenlang gar nicht commiten und updaten.
Branchen um ein Feature zu entwickeln ist ausdrücklich erlaubt und in den meisten Situationen auch erwünscht. Aber das muss halt alles zeitnah wieder zurück und der Branch aufgelöst werden.

Außerdem gilt es nur ganze Branches zu mergen und da nicht noch auf Unterordnern zu mergen. Außerdem sind die Richtungen vorgeschrieben von wo nach wo man mergt.
Dann kann man recht schnell nachvollziehen was gemerged wurde.

Die ganzen Features mögen ja alle ganz nett sein, aber damit es kein Chaos gibt ist ein hohes Maß an Disziplin und auch einiges an Erklärung nötig.
Ich kan mich noch an den Entwickler erinnern, der alle Konflikte mit Use mine ""gelöst" hatte...

Exxtreme

2012-09-24, 12:53:12

Vom TFS 2012 gibt es eine Express-Version. Und ich weiss nicht wie groß euer Team ist aber für die ersten 5 Entwickler ist es kostenlos, jeder weitere Entwickler braucht aber eine CAL. Über die Preise weiss ich nix.

Ach ja, TFS ist AFAIR schon recht anders als VSS. Sprich, es kann gut sein, dass diese Funktionalität mit den Branches jetzt nicht mehr geht.

http://www.microsoft.com/de-de/download/details.aspx?id=29919
http://www.heise.de/developer/meldung/Microsoft-kuendigt-kostenlose-Express-Variante-des-Team-Foundation-Server-an-1442050.html

minos5000

2012-09-24, 15:11:18

Grundsätzlich mal: wenn man die selben Änderungen häufiger auf verschiedenen Branchen einspielt, ist mit hoher Wahrscheinlichkeit das Branching Modell falsch.

Hmm, bei uns läuft idR so ab:
Alle Entwickler arbeiten zu Beginn auf der gleichen Version etwa v00. Wird einer mit seinem Teil fertig, arbeitet er an Features für das nächste Release v01 für welches ein Branch erstelltwird. Der nächste Entwickler der frei wird bekommt dann des öfteren ein Feature das nicht in v01 sondern erst in v02 ausgeliefert werden soll, d.h. noch ein Brunch.

Die Änderungen die währenddessen in v00 stattfinden sollen aber möglichst zeitnah auch in v01 und v02 stattfinden. Auch wenn es sich oben anders liest, bei uns sind Branches Release- und nicht Feature getrieben.
Einen Trunk wie bei SVN in dem alle Änderungen irgendwann wieder zusammenlaufen gibt es in VSS nicht, dort ist die Ursprungsversion v00 auch nur ein Brunch.

Was mich an SVN stört ist, dass Änderungen im trunk immer erst noch händisch in die Brunches übernommen werden müssen, was bei uns ziemlich häufig vorkommt. Aber wie es aussieht, müssen wir bei jedem aktuellen VVS in diesen sauren Apfel beißen.

PatkIllA

2012-09-24, 15:16:54

Der trunk im SVN ist technisch auch nur ein Branch. Der hat keinerlei technische Sonderrolle und ist auch nur eine Konvention.
Solange die Änderungen keine Konflikte hervorrufen sind das mergen auch nur ein paar Klicks oder eine Befehlszeile. Das könntest du auch automatisiert per Skript machen.
Wenn das nicht klappt hast du sofort deine Software kaputt und musst du dich händisch drum kümmern. Außerdem kann eine Änderung ja auch durchaus was im branch für die Auslieferungen kaputt machen.
Das hat IMO gute Gründe, dass sich Änderungen nicht automatisch verteilen.

Wir haben SVN und wie üblich einen trunk. Darin werden die neuen Features entwickelt. Wenn es keine neuen Features mehr für das nächste Release gibt wird ein QS-Branch erstellt.
Bugfixes entwickeln wir auf dem niedrigsten QS-Branch auf dem er gebraucht wird und der wird dann jeden QS-Branch bis zum trunk hochgemerged. Auf den QS-Branchen wird regelmäßig (ca. wöchentlich) geschaut, dass die Änderungen gemerged wurden.
Leider wird derzeit auch in den QS-Branches noch recht viel an neuen Features entwickelt, aber wir hoffen das auf notwendigste zu reduzieren.

Shink

2012-09-24, 15:49:32

Wir haben SVN und wie üblich einen trunk. Darin werden die neuen Features entwickelt. Wenn es keine neuen Features mehr für das nächste Release gibt wird ein QS-Branch erstellt.
Bugfixes entwickeln wir auf dem niedrigsten QS-Branch auf dem er gebraucht wird und der wird dann jeden QS-Branch bis zum trunk hochgemerged. Auf den QS-Branchen wird regelmäßig (ca. wöchentlich) geschaut, dass die Änderungen gemerged wurden.
So ähnlich läuft das bei uns auch. Unterschied: Bugfixes werden immer am Trunk entwickelt und in die Branches gemerged, in die es noch rein muss.

Seitdem gibt es weniger Regressionen aufgrund von "unbeabsichtigten" Fixes.

Yavion

2012-09-24, 18:25:05

Mercurial schlägt sich in meinem Umfeld bisher sehr gut.
Privat benutze ich es inzwischen auch ganz gerne.
Ich mag an Mercurial die hervorragende Intergration in Eclipse und VS, und über TortoiseHG in den Windows Explorer. Es ist genau so einfach wie SVN, ohne die technologische Altlast.

Monger

2012-09-25, 19:29:33

Was mich an SVN stört ist, dass Änderungen im trunk immer erst noch händisch in die Brunches übernommen werden müssen, was bei uns ziemlich häufig vorkommt. Aber wie es aussieht, müssen wir bei jedem aktuellen VVS in diesen sauren Apfel beißen.
Wir hatten hier vor ein paar Monaten mal einen Guru für agile Entwicklung da. Den haben wir auch mal gefragt: wieviel Branches sollte man eigentlich haben? Dass Private Branches ein ziemlicher Mist sind haben wir mittlerweile selbst erkannt, aber dazu kommen halt noch Developer, Component und Integrationsbranches bei uns...

Er hat dann mit den Schultern gezuckt und gemeint: Google entwickelt seine Softwareprodukte in aller Regel auch nur auf zwei aktiven Branches gleichzeitig: einen Release Branch, und einen Feature Branch. Die Kunst ist da, halt nur das rüberzumergen was man wirklich im Feld haben will, und mit Gated Checkins mit ausreichend Tests zu verhindern dass die bestehende Basis destabilisiert wird.

Hängt also gar nicht so sehr an der Quellverwaltung, als an dem Prozess außenrum. Mit einem Wechsel der Quellverwaltung alleine erreichst du erstmal keine Verbesserungen.

registrierter Gast

2012-09-26, 10:23:57

Er hat dann mit den Schultern gezuckt und gemeint: Google entwickelt seine Softwareprodukte in aller Regel auch nur auf zwei aktiven Branches gleichzeitig: einen Release Branch, und einen Feature Branch. Die Kunst ist da, halt nur das rüberzumergen was man wirklich im Feld haben will, und mit Gated Checkins mit ausreichend Tests zu verhindern dass die bestehende Basis destabilisiert wird.
Welche Versionsverwaltung nutzt Google?

Monger

2012-09-26, 13:13:18

Welche Versionsverwaltung nutzt Google?
Ganz ehrlich: weiß ich nicht. Aber wahrscheinlich wie die meisten großen Firmen nutzen die mehrere.

Marscel

2012-09-26, 15:54:57

Hab in der Vergangenheit das eine oder andere System genutzt, privat, an der Uni oder im Beruf:

Nach git will man kein SVN mehr. Letztens erst wieder zu SVN gezwungen worden, kA wie viele Korrekturcommits im später im Log standen weil wir kollektiv zu doof für die Benutzung waren, bei git liefs hingegen später äußerst gut, selbst für Kommandozeilenmuffel.

* kein .svn in jedem Verzeichnis, ein globales .git: das spart sämtliche Exportierei wenn man Ordner duplizieren muss; mir ist schon Software mit dynamischer Inklusion untergekommen, die im Developmentmode sich am .svn verschluckt hat. Man muss sich hinsichtlich des Dateisystems um nichts kümmern
* ich hab irgendwem dabei zugeguckt, wie man diese SVN-Konventionsbranches verwaltet: mit einer der besten Gründe für git mMn, Branchhandling geht so dermaßen leicht von der Hand, ich war hin und weg
* man kann, solange man sie noch nicht veröffentlich hat, die Commit-History bearbeiten, sodass man einen unüberlegt dämlichen Commit nochmal eben atomisieren kann, ohne dass danach was kaputt geht
* stashing: commitloses Beiseitepacken der Arbeit, falls irgendwas dazwischen kommt
* transparente Stage: was ist noch nicht getrackt, was ist neu, was ist modifiziert, was will ich in die Commitstage tun, da waren die SVN-Tools nie sehr intuitiv, in Komb. mit dem 1. Punkt kommt man schnell ist fluchen
* git diff --stat ist im Team hilfreich, um mal eben den Codeimpact zu erkennen
* git daemon, falls mal der Teamserver nicht erreichbar ist und man etwas teilen möchte
* git Hooks
* ...

Was bei git vielleicht ein paar Steine in den Weg liegt:
* weil dezentral brauchst du immer eine komplette Kopie des Repos, nach Unterpfaden lässt sich mMn nicht auschecken, sodass der Platzbedarf steigt, die Skalierung war aber auch in größeren Projekten (LibreOffice) einwandfrei
* wenn man der MSVS-AddIn-Liebhaber ist, weiß ich nicht wie gut die Integration da ist oder allgemein, was Fenstertools angeht, ich nutz es einfach parallel per Kommandozeile
* das CLI ist bei ausgeflippteren Sachen ein wenig gaga, sieht man auch an den Manpages, Mercurial scheint da aufgeräumter zu sein, ansonsten kann man im Netz aber auch viele Aliase finden

Tool- und plattformungebunden würd ich nur noch git benutzen, Mercurial hab ich nicht so stark genutzt bisher, nach Hörensagen böte sich das aber auch an. SVN freiwillig nicht nochmal.

PatkIllA

2012-09-26, 17:09:45

* kein .svn in jedem Verzeichnis, ein globales .git: das spart sämtliche Exportierei wenn man Ordner duplizieren muss; mir ist schon Software mit dynamischer Inklusion untergekommen, die im Developmentmode sich am .svn verschluckt hat. Man muss sich hinsichtlich des Dateisystems um nichts kümmern
Das mit den vielen Unterordnern ist seit SVN 1.7 Geschichte.
* ich hab irgendwem dabei zugeguckt, wie man diese SVN-Konventionsbranches verwaltet: mit einer der besten Gründe für git mMn, Branchhandling geht so dermaßen leicht von der Hand, ich war hin und wegWas geht denn da so viel leichter?
* stashing: commitloses Beiseitepacken der Arbeit, falls irgendwas dazwischen kommtIch hab zwar oft mehrmal ausgescheckt, aber sowas in der Richtung kann man doch auch mit einem Patch machen.
* transparente Stage: was ist noch nicht getrackt, was ist neu, was ist modifiziert, was will ich in die Commitstage tun, da waren die SVN-Tools nie sehr intuitiv, in Komb. mit dem 1. Punkt kommt man schnell ist fluchenKannst du erklären? Mir ist nicht klar was da mit Stage gemeint ist und was daran transparent ist. ;)

Marscel

2012-09-26, 19:00:46

Das mit den vielen Unterordnern ist seit SVN 1.7 Geschichte.

Ok, dann muss das eine 1.6er gewesen sein. Immerhin

Was geht denn da so viel leichter?

git branch neuer_branch

Zweigt von der aktuellen Location ab.

git checkout branchname

zum Hin- und Herwechseln. Das, was ich da bei SVN gesehen habe, sah nach pfadbezogenem Checkout aus, hin und hersetzen (kopieren?) von Commit-Pfaden. In SVN hab ich das nie verwendet, die Demo Branchwechsel-rein-und-raus dauerte jedenfalls um ein vielfaches länger als eben zwei bzw. drei Konsolenbefehle. Der Dozent hatte TortoiseSVN benutzt.

Ich hab zwar oft mehrmal ausgescheckt, aber sowas in der Richtung kann man doch auch mit einem Patch machen.

Du hast was, das ist nicht commitreif, das Repo ist dirty aber es kommt was dazwischen:

git stash

Wieder alles clean und zurückgesetzt, aber dein Fortschritt ist zur Seite gelegt. Du kannst also den Branch wechseln, einen Hotfix schreiben, was auch immer. Wenn du das erledigt hast:

git stash pop

Alles wieder so dirty, wie du unterbrochen wurdest. Geht stapel- wie listenbasiert. Patch geht bestimmt auch, hier sparst du dir Filehandling oder sowas.

Kannst du erklären? Mir ist nicht klar was da mit Stage gemeint ist und was daran transparent ist. ;)

Je nach Commitverhalten kriegt man davon mehr oder weniger was mit. Man fügt Dateien hinzu, bearbeitet oder löscht sie und sagt dann commit alles/den Ordner/die Datei. Bei allen ein ähnlicher Workflow. Bei git kannst du Stück für Stück die Änderungen stagen, ist ein bisschen wie diese Checklist, die man in TSVN vor dem Commit bekommt, aber praktischer: du kannst Teile einer Datei stagen, sodass du nicht zwei oder mehr semantisch unterschiedliche Dinge in der selben Datei nacheinander abarbeiten und einchecken musst (oder gar in einem daily commit unter eine Haube kehrst), sondern die Passagen auswählst, die wirklich rein sollen. Das kannst du beliebig machen, und parallel schon da weiterarbeiten, was später erst rein soll.

Wenn man immer nur ganze Dateien tracked, dann ist das eher irrelevant, aber wenns um Abschnitte geht und man aus Entwicklungsgründen eigentlich nicht rein und rauskopieren will, kann man damit den Commit besser customizen.

Aber sonst: meine Erfahrung mit SVN waren da irgendwie abenteuerlich, Löschen einer Datei/Ordner vom FS, nicht über SVN (ich glaube, das soll man nicht?), hat mir es mir ein "?" hervorgegeben, irgendwann tauchte dann wieder was auf. Angesichts git dachte ich mir, dass da irgendwas kompliziert ist. git status erkennt ohne irgendein "hey, hast du auch an mich gedacht?" was auf dem FS los ist und du kannst die Datei dann wiederholen, die Löschung bestätigen (stagen), oder sie nur aus dem Index entfernen.

Vielleicht will SVN, dass man alles erst über das CLI macht, git mischt sich da nicht ein und lässt sich so sogar problemlos unterhalb von z.B. SVN benutzen (so hab ich dann unter der Hand und exklusiv lokal mit SVN gebrancht, als ich es nutzen musste).

Gast

2012-09-27, 21:38:03

Welche Versionsverwaltung nutzt Google?Hauptsächlich Mercurial. Mit ein bedeutender Grund war die bestehende HTTP-Infrastuktur, die mit Mercurial (zumindest zum damaligen Zeitpunkt) besser genutzt werden konnte. Git hat ja noch ein eigenes Protokoll, das dort in der Regel gegenüber HTTP zu bevorzugen ist.

Gibt irgendwo ein Paper, wo sie die Entscheidungen Pro/Contra-Git/Mercurial mal ein bisschen dargelegt haben.

Exxtreme

2012-09-28, 10:23:44

Gibt irgendwo ein Paper, wo sie die Entscheidungen Pro/Contra-Git/Mercurial mal ein bisschen dargelegt haben.

Scheint das da zu sein:

http://code.google.com/p/support/wiki/DVCSAnalysis

PH4Real

2012-10-08, 22:51:27

Das Paper ist schon 4 Jahre alt... Und sie nutzen Git/Gerrit zur Android Entwicklung (wie eclipse.org auch).

Ansonsten würde ich stark zu git tendieren. Das Branchen/Mergen geht gut von der Hand und auch sonst ist es meistens sehr sehr fix, da ja viele Operationen nur lokal passieren.
Nur die Handhabung ist am Anfang etwas ungewöhnlich und es gibt fast nichts, was git nicht kann, was das ganze etwas unübersichtlich macht.

Aber selbst für den UseCase des Threadstarters gibt es ein Befehl ;):
http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html

Exxtreme

2012-10-09, 20:43:06

Wie läuft Git unter Windows? Als ich es mal testen wollte dann wollte es Cygwin haben. Da habe ich es gelassen und stattdessen Hg genommen. Und das hat astreinen Windows-Support.

PH4Real

2012-10-09, 22:51:10

Wie läuft Git unter Windows? Als ich es mal testen wollte dann wollte es Cygwin haben. Da habe ich es gelassen und stattdessen Hg genommen. Und das hat astreinen Windows-Support.

Es läuft leider etwas lahm, da es innerhalb MinGW läuft... Schneller ist es unter Windows mit egit unter eclipse ist aber etwas "oversized" wenn man eigentlich nur die Konsole braucht.
Ein nativer Client, der die Geschwindigkeit von Linux/Unix/Mac Clients erreicht ist mir nicht bekannt.

Edit: "Lahm" heißt jetzt nicht unbenutzbar, aber eben kein Vergleich zu den sehr schnellen Unix Versionen. Wenn man diese nicht kennt, fällt einem dies vielleicht nicht sofort auf.

myMind

2012-10-09, 23:24:56

Ok, dann muss das eine 1.6er gewesen sein. Immerhin

Die Verteilung des lokalen SVN-Repositories über mehrere Verzeichnisse ist - oder vielmehr war - eines der Hauptprobleme, warum man das Verschieben von Verzeichnissen bei SVN nicht so richtig in den Griff bekommen hat. Bei größeren Umbenennungs- oder Verschiebeaktionen empfiehlt es sich, dass alle User die Änderungen in dem Beriech haben einchecken und man dann die Aktionen über den TortoiseSVN Repo-Browser macht. Dann gibt es idR keine Probleme.

git branch neuer_branch

Zweigt von der aktuellen Location ab.

git checkout branchname

zum Hin- und Herwechseln. Das, was ich da bei SVN gesehen habe, sah nach pfadbezogenem Checkout aus, hin und hersetzen (kopieren?) von Commit-Pfaden. In SVN hab ich das nie verwendet, die Demo Branchwechsel-rein-und-raus dauerte jedenfalls um ein vielfaches länger als eben zwei bzw. drei Konsolenbefehle. Der Dozent hatte TortoiseSVN benutzt.

Das Branching bei SVN funktioniert nur dann gut, wenn es a) sinnvolle Teamkonventionen gibt und b) diese auch eingehalten werden. Dann geht das völlig Problemlos.

Das git checkout heißt bei Subversion svn switch.

Der Vorteil bei git liegt darin, dass man Branchingkonventionen nicht benötigt. Dafür wird es bei vielen Branches schnell unüberisichtlich.

Du hast was, das ist nicht commitreif, das Repo ist dirty aber es kommt was dazwischen:

git stash

Wieder alles clean und zurückgesetzt, aber dein Fortschritt ist zur Seite gelegt. Du kannst also den Branch wechseln, einen Hotfix schreiben, was auch immer. Wenn du das erledigt hast:

git stash pop

Alles wieder so dirty, wie du unterbrochen wurdest. Geht stapel- wie listenbasiert. Patch geht bestimmt auch, hier sparst du dir Filehandling oder sowas.

...funktioniert das auch gut mit einem richtig großen Eclipseprojekt? Ich bin da noch skeptisch. Die ersten Erfahrungen waren da eher durchwachsen.

Je nach Commitverhalten kriegt man davon mehr oder weniger was mit. Man fügt Dateien hinzu, bearbeitet oder löscht sie und sagt dann commit alles/den Ordner/die Datei. Bei allen ein ähnlicher Workflow. Bei git kannst du Stück für Stück die Änderungen stagen, ist ein bisschen wie diese Checklist, die man in TSVN vor dem Commit bekommt, aber praktischer: du kannst Teile einer Datei stagen, sodass du nicht zwei oder mehr semantisch unterschiedliche Dinge in der selben Datei nacheinander abarbeiten und einchecken musst (oder gar in einem daily commit unter eine Haube kehrst), sondern die Passagen auswählst, die wirklich rein sollen. Das kannst du beliebig machen, und parallel schon da weiterarbeiten, was später erst rein soll.

Wenn man immer nur ganze Dateien tracked, dann ist das eher irrelevant, aber wenns um Abschnitte geht und man aus Entwicklungsgründen eigentlich nicht rein und rauskopieren will, kann man damit den Commit besser customizen.

Das finde ich auch klasse. Prinzipiell kann man diese Kontextswitches auch mit jeder klassischen Versionsverwaltung machen, aber man macht es eben nicht, weil es zu kompliziert ist oder weil man seine Experimente nicht auf dem zentralen Server sehen möchte.

Aber sonst: meine Erfahrung mit SVN waren da irgendwie abenteuerlich, Löschen einer Datei/Ordner vom FS, nicht über SVN (ich glaube, das soll man nicht?), hat mir es mir ein "?" hervorgegeben, irgendwann tauchte dann wieder was auf.

Da hast Du etwas misverstanden. Wenn Du die Datei im Repository löschen willst, dann immer über svn delete.

Angesichts git dachte ich mir, dass da irgendwas kompliziert ist. git status erkennt ohne irgendein "hey, hast du auch an mich gedacht?" was auf dem FS los ist und du kannst die Datei dann wiederholen, die Löschung bestätigen (stagen), oder sie nur aus dem Index entfernen.

Vielleicht will SVN, dass man alles erst über das CLI macht, git mischt sich da nicht ein und lässt sich so sogar problemlos unterhalb von z.B. SVN benutzen (so hab ich dann unter der Hand und exklusiv lokal mit SVN gebrancht, als ich es nutzen musste).

Ob Du bei Subversion das CLI verwendest oder TortoiseSVN hängt von Deiner persönlichen Präferenz ab. Die meisten kommen mit TortoiseSVN sehr gut klar. Was mir an Subversion sehr gut gefällt, dass es mit SVNKit auch ein sehr hochwertiges Java-API gibt. Da hat man eine saubere Möglichkeit spezielle Versionsverwaltungsfunktionen zu implementieren. Wenn ich den völlig unwartbaren Verhau an Shellskripten sehe, der da häufig zusammengedengelt wird, da wird mir jedes mal übel.

Zum Originalposting möchte ich auch noch etwas sagen. Wenn beim Visual Source Safe die gleiche Datei an mehreren Stellen auftaucht, so spricht Microsoft vom "Sharing". D.h. es wird ein Link auf die Originaldatei erstellt. Ändert man die Datei, so bricht man den Link und hat auf Dateiebene gebrancht. Das Feature ist eher aus der Not geboren, denn Source Safe muss beim echten Branchen alle Dateien duplizieren. Eine Unzulänglichkeit die seit langem ausgestorben ist. Aber wie das bei MS früher so war: it's not a bug, it's a feature.

Subversion kann auch Dateien Sharen. Das Stichwort heißt svn:external. Verzeichnisse oder Dateien aus einem anderen lokalen Verzeichnis oder sogar aus einem anderen Repository können eingehängt werden. Jedoch unterstützt das Tooling in keiner Weise einen ähnlichen Workflow, wie ihn Source Safe damals kannte. Letzteres dürfte auch für den TFS zutreffen.

Wenn es darum geht, die lokale Arbeitskopie aus verschiedenen Quellen zusammenzustellen, dann ist Subversion bestens geeignet. Möglicherweise genügt das ja schon, um mit der bestehenden Struktur sinnvoll weiter arbeiten zu können.

noid

2012-10-11, 01:10:11

So ähnlich läuft das bei uns auch. Unterschied: Bugfixes werden immer am Trunk entwickelt und in die Branches gemerged, in die es noch rein muss.

Seitdem gibt es weniger Regressionen aufgrund von "unbeabsichtigten" Fixes.

Man kann das auch umdrehen - wichtig sind hier jedoch Prozesse/Vorgänge, die man einhalten tut und passendes vv auf der anderen Seite.

Ein sauberes continuous integration setup bringt einem mehr als diese Pseudosicherheit mit dutzenden branches. :freak:

edit: je nach clients würde ich svn oder hg nehmen.

Unfug

2012-10-11, 09:19:31

Wir nutzen auch Git in kleinen Teams. Sind auch erst vor kurzem Umgestiegen. Die Einarbeitung hat schon einige Tage gedauert. Um ehrlich zu sein, nutzen wir die Möglichkeiten von Git nicht aus.

Es wird ausgescheckt und eingescheckt. Wenn einer einen Branch haben sollte und etwas tolles gemacht hat, dann wird darüber diskutiert und anschließend kann dieser seinen Code direkt in den Main reinschieben. So haben wir keine Konflikte bei einem Merge. Das geht natürlich nur in Projekten, wo ich meine Mitarbeiter morgens ranholen kann (Scrum Sprints).

Bei .NET hat man noch die Möglichkeit von partiellen Klassen, wodurch ein mergen unnötig wird (vorausgesetzt eine gute Spezifikation existiert). Das haben wir auch schon genutzt (in einem 4er Team) und haben damit sehr erfolgreich unser Projekt schnell abgeschlossen und hatten quasi nur ein Main Repository.

Aber den TFS muss ich aber auch nochmal unbedingt ausprobieren. Höre überall, dass der total super sei.

universaL

2012-10-11, 13:36:55

moin,

ich benutze quasi nurnoch git. Ein wie cih finde nettes Branching/Merging-modell: http://nvie.com/posts/a-successful-git-branching-model/

Nasenbaer

2012-10-12, 22:58:21

Weil hier git oft vorgeschlagen wurde: Ich habe irgendwo vor kurzem gelesen, dass git für Binärdaten sehr ungeeignet sein soll. Falls ihr sowas mit eincheckt, sollte man sich in der Hinsicht vielleicht nochmals genauer informieren.

In dem Zusammenhang wäre dann vielleicht auch Avid Alienbrain (http://de.wikipedia.org/wiki/Alienbrain) interessant. Andererseits hättest du diese Anforderung dann warscheinlich schon im Eingangspost erwähnt. :redface:

Für den Fall, dass git doch ne Option ist, ist das kostenlose Git-Book vielleicht auch was: http://git-scm.com/book/de

DanMan

2012-10-24, 21:09:10

Git, Mercurial oder Bazaar. Alles andere ist Gestern.
Thread beendet nach dem ersten Reply. :D

Stimme dem zu. Von den Features unterscheiden sich alle 3 nicht sonderlich.

Git ist wohl von Haus aus am umfangreichsten, dadurch aber auch etwas komplizierter, und eben der bescheidene Windows-Support.
Mercurial (mein Favorit) ist von Haus aus einfacher gestrickt, kann aber durch Plugins problemlos werden, so dass es git in nichts nachsteht. Im Gebrauch näher an SVN als git.
Bazaar ist vom Tooling her noch nicht so verbreitet (kein brauchbares Eclipse-Plugin z.B.), dadurch ist man auf den eigenen Client angewiesen. Kommt mir generell noch etwas grün hinter den Ohren vor.

Zum Workflow:
Features branch ich mittlerweile am liebsten, indem ich das komplette Repo. kopiere, anstatt innerhalb des Repos. zu branchen. So wird man den Branch am einfachsten wieder los, wenn man Mist gebaut hat: Ordner löschen, fertig.

Gegen SVN spricht eigentlich nur, dass nichts dafür spricht. :)
Gibt für meine Begriffe nix das SVN kann, was die anderen nicht auch könnten. Die haben aber den Vorteil - wie ich finde - serverlos zu sein. Was nicht heißt, dass man sich nicht trotzdem einen Client-Server Workflow unterwerfen kann, wenn man das will/braucht.