Welches SCM benutzt ihr?

[DEvent]

;fricky schrieb:

guenni81 schrieb:

Ja, git ist ein dezentrales System, was aber nicht heißt das man dennoch ein Zentrales Repository einrichten kann (muß man aber natürlich nicht).

aber wie machen sie's denn, dass die projekte nicht divergieren? z.b. projektstarter A beginnt, B klont von A, C klont von B und gibt änderungen brav zurück, B gibt änderungen aber niemals an A weiter, so dass A von B und C nichts mitbekommt. d.h. B und C sind mit A dauerhaft 'out of sync'. da muss doch irgendein system dahinterstecken, das sowas auschliesst.

Deswegen haben die Commits in Git einen Sha-Hash. Das zwei unterschiedliche Commits den gleich Hash haben ist so gut wie ausgeschlossen und wird auch in der Praxis wohl nie passieren. Mit deinem Beispiel sehe ich gar keine Probleme. Wenn das ganze irgendwas ge-merge wird, gibt es halt paar merge-conflicts.

Die Sha-Hashs haben schon etliche Vorteile, gegenüber einer einfachen Nummerierung. Weil Commit-Inhalt=Sha-Hash ist, ist auch merge sehr viel schneller in Git. Nach 300 commits hast du eh die Übersicht über die Nummern verloren.

Zu Branches in SVN, die musst du aber auch öffentlich auf den Server machen. Ausserdem ist Mergen sehr schwierig in SVN, wogegen in Git mergen in Sekunden geht.

[;fricky]

HyperSonic schrieb:

Was man dort zum Beispiel machen kann, ist einen öffentlichen Server aufzustellen, von dem sich alle Änderungen holen bzw. das sie initial clonen. Dort schieben sie ihre eigenen Änderungen aber nicht rein. Statt dessen gibt es einen Integrator, der sich bei den Leuten die Änderungen holt und sie dann zu einem funktionierenden Stand zusammenbastelt und auf den Server schiebt von dem alle ihre Änderungen holen (Wenn ihm das zu kompliziert ist, kann er auch sagen: "Du nimm mal den stand hier und integriere dein zeuch da rein" und sich erst dann den Stand holen).

und der 'integrator' ist ein mensch, d.h. hier ist handarbeit gefragt? in dem fall wird git nur wie eine 'lokale history' benutzt (hey, manche IDEs haben sowas standardmässig eingebaut *fg*, intelliJ z.b.). ausserdem hat man dann ja doch wieder ein zentralisiertes system (das zudem noch einen einem verwalter 'ne menge arbeit beschert). naja, nichts für ungut, aber ich dachte, auch nach der ganzen schwärmerei, in threads wie in diesem, dass git irgendwie intelligenter wär. aber danke für die gute erklärung.
btw, ich hab' auch mal bei wikipedia geschaut, da steht z.b., dass manche git so benutzen:

Die Übertragung in das „offizielle Repository“ eines Projekts erfolgt häufig in Form von Patches, die via E-Mail an den Entwickler oder eine Entwicklungs-Mailing-Liste geschickt werden.

^^ na denn...

DEvent schrieb:

Deswegen haben die Commits in Git einen Sha-Hash. Das zwei unterschiedliche Commits den gleich Hash haben ist so gut wie ausgeschlossen und wird auch in der Praxis wohl nie passieren.

commits sind auch in herkömmlichen VCSs eindeutig, anders würde es doch garnicht gehen.

DEvent schrieb:

Die Sha-Hashs haben schon etliche Vorteile, gegenüber einer einfachen Nummerierung. Weil Commit-Inhalt=Sha-Hash ist, ist auch merge sehr viel schneller in Git.

git ist schneller, weil alles nur auf deinem rechner passiert. die handarbeit des menschlichen 'integrators' (siehe oben), wird wohl alles andere als schnell sein. *fg*

[byto]

@;fricky
Integratoren wirst Du ja auch nur dann benutzen, wenn Du nicht jedem Hansel erlauben willst, ins Repository zu commiten. Dont call us, we call you! Nimm z.B. ein Open Source Projekt mit 100en "Commitern". Wenn die alle wie sie lustig sind, ins Repo commiten können, könnte es ziemlich chaotisch ablaufen. Da wärs sehr hilfreich, wenn einer oder wenige die Kontrolle haben, wer was wann commitet.
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. Von dem Repo. werden dann die Nightly Builds gemacht bzw. dann die Releases.

[;fricky]

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.

[byto]

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.

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

[;fricky]

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.