3. Welches SCM benutzt ihr?

Welches SCM benutzt ihr?

  • D

    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.

    0
  • N

    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.

    0
  • N

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

    0
  • N

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

    0
  • ?

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

    0
  • B

    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.

    0
  • D

    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

    0
  • B

    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.

    0
  • N

    ;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. 🙂

    0
  • ?

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

    0
  • B

    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.

    0
  • B

    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?

    0
  • E

    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.

    0
  • M

    Blue-Tiger schrieb:

    Mich wuerd mal interessieren wie granular eure git commits sind?

    So klein wie möglich. Allerdings nur so granular, dass ich nicht ständig git add -p oder -i verwenden muss. Gesquasht wird nicht, oder nur extrem selten.

    0
  • D

    Blue-Tiger schrieb:

    Mich wuerd mal interessieren wie granular eure git commits sind?

    Ich habe ebenso einen Dev. branch, devent und commite nach jedem fertigen Zwischenschritt. Wenn ich fertig bin, merge ich alles in master und pushe es zum Server.

    0
  • M

    DEvent schrieb:

    Blue-Tiger schrieb:

    Mich wuerd mal interessieren wie granular eure git commits sind?

    Ich habe ebenso einen Dev. branch, devent und commite nach jedem fertigen Zwischenschritt. Wenn ich fertig bin, merge ich alles in master und pushe es zum Server.

    Und was, wenn du mehrere Feature-Branches hast? Gibts dann eine devent.<FEATURE> Branch für jedes Feature?

    0
  • D

    Mr. N schrieb:

    DEvent schrieb:

    Blue-Tiger schrieb:

    Mich wuerd mal interessieren wie granular eure git commits sind?

    Ich habe ebenso einen Dev. branch, devent und commite nach jedem fertigen Zwischenschritt. Wenn ich fertig bin, merge ich alles in master und pushe es zum Server.

    Und was, wenn du mehrere Feature-Branches hast? Gibts dann eine devent.<FEATURE> Branch für jedes Feature?

    Oder einfach <FEATURE> . Man braucht kein Namespace für Git. devent ist halt mein Dev.-Branch.

    0
  • M

    DEvent schrieb:

    Oder einfach <FEATURE> . Man braucht kein Namespace für Git. devent ist halt mein Dev.-Branch.

    Ja, aber benutzt du die devent-Branch auch für Entwicklung in Feature-Branches? Das wird ja eigentlich wohl kaum gehen... Also musst du entweder direkt in der Feature-Branch entwickeln, oder eine eigene Dev-Branch für die Feature-Branch einrichten.

    Aber ehrlich gesagt halte ich ohnehin nichts von Dev-Branches. Ich habe hier eine master-Branch und viele Feature-Branches. Und für alte Release-Serien eben Release-Branches bei Bedarf (also wenn z.B. 0.10 aktuell ist, gibt es eine release-0.9 Branch für die Entwicklung der 0.9.x Serie).

    0
  • B

    Mr. N schrieb:

    Blue-Tiger schrieb:

    Mich wuerd mal interessieren wie granular eure git commits sind?

    So klein wie möglich. Allerdings nur so granular, dass ich nicht ständig git add -p oder -i verwenden muss. Gesquasht wird nicht, oder nur extrem selten.

    aber hast dann nicht ein furchtbar unuebersichtliches log/history?

    BTW: loescht du feature-branches, wenn sie fertig implementiert sind, oder behaelst du sie bei (oder verwendest sie gar weiter)?

    0
  • D

    Blue-Tiger schrieb:

    Mr. N schrieb:

    Blue-Tiger schrieb:

    Mich wuerd mal interessieren wie granular eure git commits sind?

    So klein wie möglich. Allerdings nur so granular, dass ich nicht ständig git add -p oder -i verwenden muss. Gesquasht wird nicht, oder nur extrem selten.

    aber hast dann nicht ein furchtbar unuebersichtliches log/history?

    Ein Log sollte doch dokumentieren welche Änderung wieso gemacht wurde. Da sind viele kleinere commits doch besser als ein großer commit?

    0
Anmelden zum Antworten