Welches SCM benutzt ihr?

DEvent

;fricky schrieb:

byto schrieb:

Bei "normalen" Projektteams mit einer überschaubaren Größe wirds wohl eher so laufen, dass es ein Master-Repository gibt, in das jeder seine Features und Bugfixes commiten kann, wenn sie fertig sind.

das denke ich auch, commit-rechte beim server haben in der regel nur projektmitglieder, also alles wie gehabt, nur dass das, was bei SVN 'commit', bei git 'push' heisst und SVNs 'update' heisst unter git 'rebase' oder so ähnlich. man kann git also auch als ganz gewöhnliches, server-basiertes VCS nutzen. vorteil aber auch nachteil von git ist, dass eine lokale history mitläuft, was vielleicht viele dazu bringt, seltener kontakt mit dem 'main-repository' aufzunehmen. andererseits braucht man keine backups vom main-repository anzulegen, weil es sowieso als kopie auf jedem entwicklungsrechner vorhanden ist, aber wenn lokal was schiefgeht, ist gleich die arbeit (eines entwicklers) von mehreren tagen futsch.

Das versucht man einem die ganze Zeit zu erklären, dass du Git wie SVN benutzen kannst, ohne die ganzen Nachteile von SVN. Aber jeder denkt, dass man ein distribute SCM nur dezentral, ohne Server, benutzen kann. Git kannst du eben mit einen zentralen Server, ohne einen Server, mit Intergrator oder ohne, usw. benutzen. Wie es dem Projekt am besten ist.

Wenn z.B. der Master-Server ausfällt, kann ich schnell die Änderungen an meinen Kollegen pushen, dessen Computer nun als Master-Server funktionieren kann. Der Kollege braucht nur den git-daemon oder ssh zu installieren. Fällt das gesamte Netzwerk aus, kann man den Master auf ein USB Stick kopieren und den Stick herumreichen.

DEvent

byto schrieb:

Ich sehe das so ähnlich. Habe bisher nicht mit Git gearbeitet, finde das was ich bisher gelesen habe durchaus interessant, aber teilweise ist das imho ein zweischneidiges Schwert. Häufig lese ich, dass Git häufiges Commiten fördert und dass das bei SVN wegen des schwierigen Mergens nicht passieren würde. Bei mir ist das aber genau umgekehrt: ich synchronisiere mehrmals täglich vom SVN und mache auch mehrmals täglich Commits. Je länger man wartet, umso größer ist die Gefahr, dass man viel mergen muss.

Der große Vorteil von Git scheint ja zu sein, dass jeder Entwickler zusätzlich zum Master Repo. noch sein eigenes Repo. hat, wo er beliebig branchen kann. Ist nicht die Konsequenz daraus, dass man viel mehr mit seinem privaten Repo. arbeitet und viel seltener ins Master Repo. commitet? Ich weiss nicht, ob das so vorteilhaft ist. Bei SVN habe ich immer einen Überblick, was die anderen Entwickler machen. Bei Git kocht eher jeder sein eigenes Süppchen.

Das ist doch der wichtigste Vorteil. So kann ich meine Änderungen inkrementell machen, ohne das gesamte Team zu nerven. Wenn ich ferdig bin, aktualisiere ich lokal master , merge lokal meine Änderungen in master und schaue ob nichts kaputt ist. Wenn ich mir sicher bin, dass alles Funktioniert, kann ich dann den lokalen master auf den Server pushen. Der nächste Entwickler holt sich nun den aktuellen master und macht das gleiche.

Da alle Änderungen, die etwas kaputt machen können, nur lokal passieren, kriegt der Rest des Teams nichts davon mit.

Burkhi

Es fehlt noch die Option "Andere...". Wir benutzen CM Synergy.

byto

DEvent schrieb:

Das ist doch der wichtigste Vorteil. So kann ich meine Änderungen inkrementell machen, ohne das gesamte Team zu nerven. Wenn ich ferdig bin, aktualisiere ich lokal master , merge lokal meine Änderungen in master und schaue ob nichts kaputt ist. Wenn ich mir sicher bin, dass alles Funktioniert, kann ich dann den lokalen master auf den Server pushen. Der nächste Entwickler holt sich nun den aktuellen master und macht das gleiche.

Da alle Änderungen, die etwas kaputt machen können, nur lokal passieren, kriegt der Rest des Teams nichts davon mit.

Ist aber bei SVN im Grunde das gleiche. Wenn man häufig synchronisiert, hat man immer nahezu den aktuellen Stand des Masters. Die Änderungen kann man lokal testen. Wenn alles funktioniert, wird in den Master commitet. Im Idealfall prüft der Continous Integration Server noch vor dem Commit, ob die Unittests nach der Änderung noch grün sind + evtl. bestimmte Code Style Metriken etc. Läuft irgendwas schief, wird der Commit abgebrochen. Ansonsten ist der Code commitet und die anderen Entwickler können synchronisieren.

Vorteile von Git sehe ich aber vor allem bei sehr großen Projekten und entsprechend vielen Entwicklern. Da könnte man dann sehr gut für verschiedene Module mehrere Master Repositories anlegen, in die die einzelnen Teams dann commiten. Aus diesen einzelnen Master Repositories wird dann in ein Super Repository commitet und der Build angestoßen.

Klar hat Git auch andere Vorteile, aber die Möglichkeit, private Repositories und Branches anzulegen, ist imo ein zweischneidiges Schwert. Das verführt doch nur dazu, über längere Zeit nicht ins Master Repository zu commiten.

nman

;fricky schrieb:

nicht weiter schlimm, da du ja zum entwickeln und experimentieren branches anlegen kannst bzw. releases sowieso 'getaggt' sind.

Branching mit SVN ist ziemlich kaputt. Bzw. das Branchen geht ja noch, das Mergen ist aber einfach kaputt.

da geht nix kaputt, es ist ja gerade das wesen eines jeden VCS, dass du beliebige stände wieder hervorholen kannst.

Natürlich kannst Du alles wieder herstellen. Aber mit lokalen Feature-Branches und Rebase kannst Du gezielt nur an ein paar Features arbeiten und diese dann wenn sie soweit fertig sind, dass sie nichts anderes zerschießen, pushen. Ohne irgendwas zu zerschießen.

nman schrieb:

- Wenn ich im Flieger sitze oder irgendwo mitten in der Pampa, wo ich keinen Internetzugang habe, kann ich nicht committen, nicht updaten, nicht vernünftig Regressionen debuggen oä.

stimmt allerdings, aber wenn du offline versionskontrolle brauchst, tut's ja ein lokales VCS, wobei du dann wieder vor den gleichen problemchen stehst, wie mit allen lokalen kopien: wenn die pestflatte den geist aufgibt, oder dein schlepptopp geklaut wird...

Aber als genau so ein "lokales VCS" fungiert doch Git:
- Jedes Verzeichnis in dem ich "git init" mache, ist ein Git Repo.
- Dieses Verzeichnis kann ich dann auch überall hinpushen bzw. Leute von mir klonen und pullen lassen oä.
- Dh. ob Du Offline oder Online bist, ist völlig egal, Du hast immer das Repo, mit dem Du normalerweise arbeitest zur Verfügung. Und sobald Du das nächste Mal "push" machst, sind Deine Daten meinetwegen auch auf dem bestens gesicherten und gebackupten zentralen Server.

rüdiger

@;fricky
Am einfachsten ist es wohl, wenn man einen zentralen Server nutzt, um die Projektarbeit zu koordinieren. So wird das sicher bei den meisten Projekten gemacht. Wenn jemand fremdes nun einen Patch hat, dann kann man ein Entwickler den einspielen, da git zwischen Autor und Submitter unterscheiden kann.

Aber wie bereits gesagt wurde, ist Git da sehr flexibel, was die Arbeitsstrategien angeht. Die Linux Leute nehmen zB ein System aus mehreren Maintainern, die eben Patches und Arbeiten von Entwicklern sammeln und am Ende wird das eine Etage höher geleitet, bis dann das Release gemacht wird.

byto schrieb:

Ist nicht die Konsequenz daraus, dass man viel mehr mit seinem privaten Repo. arbeitet und viel seltener ins Master Repo. commitet?

Das hängt sicher vom Entwickler ab, aber ich pushe meine Änderungen eigentlich sofort zum Master. Sonst hat man ja das gleiche Problem, wie bei SVN auch, dass das mergen komplizierter wird und man sich Konflikte einhandelt.

nman

MasterK schrieb:

Sehr merkwürdig... sobald leute git benutzen, scheinen sie zu vergessen, dass auch SVN sehr wohl branches kennt.

Ich habe lange mit Subversion gearbeitet und das Branching/Merging dort ist nicht vernünftig benutzbar, weil das Mergen so ein Riesenkrampf ist.

Auch bei git musst du doch irgendwann deinen code in den "master" bringen. Und da musst du auch vorher sicherstellen, dass danach noch alles funktioniert. Nur haste bei git eben dein zeugs lokal und bei SVN im branch auf dem server. Was wiederum den vorteil hat, dass da auch ein kollege mal weiterarbeiten kann wenn du zB krank bist und all deinen code nur auf deinem rechner hast an den kein anderer rankommt...

Die Merges bzw. Rebases funktionieren bei Git allerdings sehr gut, das ist eine Trivialität verglichen damit, welche Tänze man mit SVN bewerkstelligen muss.
Und: Ich kann meine eigenen Feature-Branches natürlich auch zum Server pushen, keine Ahnung woher Du entnimmst, dass das nicht geht.

Was aber nur dann ein nachteil ist, wenn man in der pampa arbeitet. Was eher für die wenigsten zutrifft.

Oder eben auf Langstreckenflügen oder irgendwo im Ausland, wo man keine zuverlässige Internetverbindung hat. Ich kenne viele Leute, auf die das zutrifft.

Es gibt drei Vorteile des Offline-Arbeiten:
- Arbeiten ohne (zuverlässige/schnelle/…) Internetverbindung möglich.
- Server ist nicht mehr Single-Point-Of-Failure.
- Alle Operationen, die normalerweise den Server benötigen werden viel schneller.

Kannst du bei git denn nur teile einer datei commiten oder wie verhinderst du da dann das "vermischen" von feature und bugfix?

Einerseits: Ja. Andererseits gibt es git stash und funktionierende Branches.

Offenbar führt git dazu, dass man vergisst wie das mit den branches in SVN funktioniert.

Ehrlich gesagt: Die Branches in SVN funktionieren auch nicht. Natürlich verwendet man die notgedrungen, aber wenn ich beim Branchen immer im Hinterkopf habe, dass das Mergen eine non-triviale und zeitaufwändige Aktion wird, dann arbeite ich völlig anders, als wenn ich weiß, dass ich mich darauf verlassen kann und der Merge nicht länger als ein paar Sekunden dauert.

edit: Ich kann nicht quoten.

DEvent

nman schrieb:

Ehrlich gesagt: Die Branches in SVN funktionieren auch nicht. Natürlich verwendet man die notgedrungen, aber wenn ich beim Branchen immer im Hinterkopf habe, dass das Mergen eine non-triviale und zeitaufwändige Aktion wird, dann arbeite ich völlig anders, als wenn ich weiß, dass ich mich darauf verlassen kann und der Merge nicht länger als ein paar Sekunden dauert.

Ein paar Sekunden? Wie groß ist den euer Projekt? Den größten merge hatte ich etwas über 1500SLOC add/remove, das war in einem Wimpernschlag erledigt.

nman

byto schrieb:

Ist aber bei SVN im Grunde das gleiche. Wenn man häufig synchronisiert, hat man immer nahezu den aktuellen Stand des Masters. Die Änderungen kann man lokal testen.

Aber nicht lokal committen.

Vorteile von Git sehe ich aber vor allem bei sehr großen Projekten und entsprechend vielen Entwicklern. Da könnte man dann sehr gut für verschiedene Module mehrere Master Repositories anlegen, in die die einzelnen Teams dann commiten.

Interessant ist für richtig große Projekte eigentlich schonmal, wie klein Git Repos sind. Es gab mal ein Projekt, wo jemand versucht hat, die alten Bitkeeper-Repos von Linux in ein Subversion-Repo zu importieren. Das funktionierte soweit ich mich erinnern kann sogar ganz gut, allerdings war das Repo, das auf diese Weise entstand, um ein Vielfaches größer als das entsprechende CVS-Repo, das wiederum schon vergleichsweise dick war.

Klar hat Git auch andere Vorteile, aber die Möglichkeit, private Repositories und Branches anzulegen, ist imo ein zweischneidiges Schwert. Das verführt doch nur dazu, über längere Zeit nicht ins Master Repository zu commiten.

Ich habe die Befürchtung schon oft gehört, aber bis dato noch nichts entsprechendes gesehen. Wo die Begründungen hierfür zu suchen sind, kann ich Dir aber auch nicht sagen.

nman

DEvent schrieb:

Ein paar Sekunden? Wie groß ist den euer Projekt? Den größten merge hatte ich etwas über 1500SLOC add/remove, das war in einem Wimpernschlag erledigt.

Ich meinte inklusive "Shell suchen, 'git merge …' tippen" bzw. "GUI öffnen, Merge anstoßen".

nman

Ein großes Missverständnis: Git ist kein "dezentrales" VCS. Git ist ein "verteiltes" VCS. Dh. Git _kann_ dezentral verwendet werden, Git kann aber auch in ganz klassischen zentralisierten Setups benutzt werden, oder auch in Mischformen, auf die ohnehin schon einige Male eingegangen wurde.

;fricky schrieb:

also alles wie gehabt, nur dass das, was bei SVN 'commit', bei git 'push' heisst und SVNs 'update' heisst unter git 'rebase' oder so ähnlich.

Nein, commit bei Subversion entspricht bei Git commit+push, allerdings kannst Du commit eben auch nur lokal benutzen, ohne sofort zu pushen.
Das, was bei SVN update heißt, ist bei Git "pull", was das selbe macht wie "fetch+merge" (also Änderungen holen und gleich mergen).
Ich bin mir ziemlich sicher, dass Du nicht verstanden hast, was "git rebase" macht, SVN hat auch nichts entsprechendes soweit ich weiß.

DEvent schrieb:

Das versucht man einem die ganze Zeit zu erklären, dass du Git wie SVN benutzen kannst, ohne die ganzen Nachteile von SVN. Aber jeder denkt, dass man ein distribute SCM nur dezentral, ohne Server, benutzen kann.

naja, dass man git wie ein gewöhnliches, serverbasiertes VCS benutzen kann, wird durch eure ständigen lobhudeleien auch nicht besonders deutlich. ich war z.b. bis gestern noch der meinung, dass es sich bei git um ein hochintelligentes verteiltes system handelt, das alle kopien desselben repositories auf 'magische weise' selbst synchronisiert. in wirklichkeit sieht's wohl doch so aus, dass git oft in zusammenhang mit einem zentralen master-repository eingesetzt wird, das sich auf 'nem server befindet.

nman schrieb:

stimmt allerdings, aber wenn du offline versionskontrolle brauchst, tut's ja ein lokales VCS, wobei du dann wieder vor den gleichen problemchen stehst, wie mit allen lokalen kopien: wenn die pestflatte den geist aufgibt, oder dein schlepptopp geklaut wird...

Aber als genau so ein "lokales VCS" fungiert doch Git:
- Jedes Verzeichnis in dem ich "git init" mache, ist ein Git Repo.
- Dieses Verzeichnis kann ich dann auch überall hinpushen bzw. Leute von mir klonen und pullen lassen oä.
- Dh. ob Du Offline oder Online bist, ist völlig egal, Du hast immer das Repo, mit dem Du normalerweise arbeitest zur Verfügung. Und sobald Du das nächste Mal "push" machst, sind Deine Daten meinetwegen auch auf dem bestens gesicherten und gebackupten zentralen Server.

^^ich meinte ja auch ein beliebiges VCS, das lokal installiert wird. ähnliches bekommst du auch mit 'svnsync' hin, aber vermutlich isses hierbei nicht ganz so flexibel wie git.

byto

Werde mir Git demnächst mal anschauen, halte es aber für schwierig, bestehende Projekte zu migrieren. Dafür muss erstmal die Bereitschaft jedes einzelnen Entwicklers da sein. Man müsste also erstmal sehr viel Überzeugungsarbeit leisten, um von einem SVN auf Git zu wechseln. Das ist imo auch der Grund, warum SVN immernoch so weit verbreitet ist.

DEvent

byto schrieb:

Werde mir Git demnächst mal anschauen, halte es aber für schwierig, bestehende Projekte zu migrieren. Dafür muss erstmal die Bereitschaft jedes einzelnen Entwicklers da sein. Man müsste also erstmal sehr viel Überzeugungsarbeit leisten, um von einem SVN auf Git zu wechseln. Das ist imo auch der Grund, warum SVN immernoch so weit verbreitet ist.

Dafür gibt es auch git-svn. Du hast ein SVN Repository, kannst aber alle Git Befehle benutzen.

git-svn - Bidirectional operation between a single Subversion branch and git

byto

Interessant. Aber wir benutzen SVN eigentlich nur über die IDE (derzeit Eclipse). Werde demnächst auf Intellij IDEA umsteigen und dort dann mal den Git Support testen.

Bei Intellij IDEA gibt es ein einheitliches UI für alle VCS, die unterstützt werden (SVN, CVS, Git und mehr). Insofern wäre die Umgewöhnung womöglich recht einfach.

nman

;fricky schrieb:

naja, dass man git wie ein gewöhnliches, serverbasiertes VCS benutzen kann, wird durch eure ständigen lobhudeleien auch nicht besonders deutlich. ich war z.b. bis gestern noch der meinung, dass es sich bei git um ein hochintelligentes verteiltes system handelt, das alle kopien desselben repositories auf 'magische weise' selbst synchronisiert.

Hm… Dass sich Git für stinknormale zentralisierte Setups benutzen lässt, wird eigentlich auf allen verlinkten Seiten und wohl sogar im Wikipedia-Artikel sehr früh erwähnt. Woher Du die Idee mit dem magischen selbst synchronisieren hast, weiß ich nicht, da muss man ja auch misstrauisch werden.

^^ich meinte ja auch ein beliebiges VCS, das lokal installiert wird. ähnliches bekommst du auch mit 'svnsync' hin, aber vermutlich isses hierbei nicht ganz so flexibel wie git.

Der Unterschied ist unter anderem der, dass "lokale Installation" bei Git bedeutet, dass Du Deinen Paketmanager oder den Installer anwirfst und eben nicht irgendwie groß Repos administrieren musst, wie bei nicht verteilten VCS.

Und dass svnsync eine ziemlich gewaltige Krücke ist, weißt Du ja selbst.

byto schrieb:

Werde mir Git demnächst mal anschauen, halte es aber für schwierig, bestehende Projekte zu migrieren. Dafür muss erstmal die Bereitschaft jedes einzelnen Entwicklers da sein. Man müsste also erstmal sehr viel Überzeugungsarbeit leisten, um von einem SVN auf Git zu wechseln. Das ist imo auch der Grund, warum SVN immernoch so weit verbreitet ist.

klar, solange SVN tut was es soll, sehen viele keinen grund zum umstieg. ich würde mich auch damit schwertun, ausser vielleicht, ich dürfte öfters mal tagelang programmieren, ohne dass eine internetverbindung in reichweite ist.

byto schrieb:

Interessant. Aber wir benutzen SVN eigentlich nur über die IDE (derzeit Eclipse). Werde demnächst auf Intellij IDEA umsteigen und dort dann mal den Git Support testen.

hihi, intelliJ hat doch schon sein eigenes mini-VCS eingebaut, das bei jedem compile/build, run/debug und refactorings usw. automatisch committed. ein paar tage loggt das auch alle änderungen mit (irgendwann fliegen wohl die ältesten raus). da brauchste wohl kein zweites lokales VCS, das alle entwicklungsschritte mitspeichert. ein repository auf einem server ersetzt das natürlich nicht.

nman schrieb:

Woher Du die Idee mit dem magischen selbst synchronisieren hast, weiß ich nicht, da muss man ja auch misstrauisch werden.

ich hab's mir eingebildet, aber die vorstellung finde ich nicht schlecht. vielleicht gibt es sowas ja schon (oder irgendwann mal).

byto

Es gibt eine Local History (hat Eclipse übrigens auch). Das würde ich aber nicht als vollwertiges lokales VCS bezeichnen.

SVN hat definitiv Schwächen beim Mergen zwischen verschiedenen Branches. Und Branching allgemein könnte auch besser sein. Wenn ich z.B. einen neuen Branch erzeuge, dann muss ich erst umständlich in Eclipse einen neuen Workspace anlegen und den Branch auschecken. Änderungen aus dem Branch dann in den Trunk zu mergen ist auch recht umständlich. Man hat sich mit der Zeit halt damit arrangiert.

Blue-Tiger

Mich wuerd mal interessieren wie granular eure git commits sind? commitet ihr nur fertige Features oder auch Zwischenschritte? Halbfertige Zwischenschritte?
Und falls ihr mehr als nur komplette Features commited: gehen die nur in die branch, in die ihr grad arbeitet (bzw. ins lokale Repo), und werden danach zu einem einzelnen kommit fuer den localen master (globalen Master) gesquashed?
Wie handhabt ihr sowas?

EXDW

Ich hatte es glaub ich schon geschrieben.
Ich entwickel in einem dev Branch, und submitte immer wenn ich den PC aus mache, egal ob es fertig ist oder nicht, auch egal ob es überhaupt baut.
Immer wenn dann ein Feature fertig ist, Merge ich es nach main und label dort zusätzlich.
So habe ich in main die letzte Stable und in dev das aktuellste.