Oliver__ schrieb am 5. November 2009 15:35
> ak17 schrieb am 5. November 2009 14:47
...
> > http://blogs.open.collab.net/svn/2008/07/subversion-merg.html lesen
> > und weinen.
>
> Danke, werde ich mal nachlesen, was so die "offizielle Seite" dazu
> meint.
Das ist so offiziell, wie es geht. Lustig finde ich den Tenor 'ist
nicht so gut, wie es hätte sein sollen, aber besser als was wir
vorher hatten'.
...
> Ich bin mir jetzt nicht sicher, ob ich das richtig verstanden habe.
> Wie ich anderswo hier gelesen habe, beinhaltet eine Git "working
> copy" immer den GANZEN repository Baum lokal auf der Festplatte. Man
> kann also lokal - ohne Netzverbindung - zwischen den branches mergen,
> wenn ich das richtig verstanden habe.
Genau. "Wie cool ist das denn" oder so. Nebenbei ist das Repo
üblichweise kleiner als die 'pristine copies', die svn mit in die
Sandbox legt, um 'svn diff' lokal machen zu können.
> Was meinst du mit "immer der ganze Baum gemergt"? Heisst das, wenn
> ich meine lokalen Aenderungen auf den "Git Server" zurueckkopieren
> ("pushen"?) will, dass dann immer alles auf einmal ("alle branches")
> dort gemerged werden?
Nein, welche Branches Du pusht (und wohin), kannst Du wählen.
git sieht seinen Inhalt (jeden Commit) jeweils als einen Baum an, und
zwei Branches werden immer nur als Ganzes gemergt, anders als bei svn
und cvs, wo man auch nur selektiv Teilbäume (also Teile eines
Projekts) mergen kann. Ob das irgendwann ein ernsthaftes Hindernis
ist, habe ich noch nicht rausgefunden; jedenfalls funktionieren
bestimmte Modelle, die unter CVS gingen, so nicht: Nämlich einen
Allzweckbranch zu machen und jeweils nur bestimmte Teile oder gar
Dateien in den Trunk zu bringen; das geht bestenfalls, indem man
bestimmte Commits selektiv in den Trunk 'transplantiert' (cherry
picking). Man muß daran halt vorher denken und wirklich ggf. separate
Feature Branches machen.
Hmm, vielleicht sollte ich doch Git-Schulungen/Support machen?
Andreas