blackiwid schrieb am 7. Juni 2011 11:45
> Dann weiter ein Merge machst du erstmal lokal, wenns dir taugt und du
> sagst sieht gut aus pusht du es zu nem Server z.B. wenn du bei svn
> mist machst beim merge, legst damit den server lahm und alle müssen
> warten bis du es gefixt hast.
Feature Branch => in die Working Copy vom Trunk mergen => Testen =>
in den Trunk Committen
Keiner muss warten und selbst wenn man Mist committed kann man ja
immer noch reverten.
> > Merge => kein Konflikt => Super. Über den Fall brauchen wir hier echt
> > nicht zu diskutieren ;)
>
> Doch Zeit, wenn du jeden tag 100x Commitest und bei svn jeder Commit
> im schnitt 10 sekunden dauert sind das 1000 Sekunden -> sind das fast
> 30 Minuten.
Du willst mir nicht gerade wirklich weismachen, dass du alle 5
Minuten ein Commit machst?
> Ja man kann dort einfach mehr Falsch machen, wie gesagt das man ein
> Tag bearbeiten kann was ja eigentlich nicht sinnvoll ist, geht
> einfach mal nicht ohne ganz spezielle commandos.
Der Fehler passiert einem vieleicht ein oder zwei mal und nie wieder.
Außerdem kann es sehr wohl sinnvol sein einen Tag zu bearbeiten. Zum
Beispiel um mal eben einen wirklich dringenden Bugfix einzuspielen.
> Dann muss man bei nem merge wissen wenn man den Branch erzeugt hat
> bei welchem Commit, das sollte SVN eigentlich wissen tuts aber nicht.
Musst du nicht. Üblicherweise willst du ja einen fertigen Endstand
aus dem Branch auf den Hauptzweig zurückspielen.
> Und wie gesagt ein Branch erzeugen, dauert bei SVN oft sehr lang, bei
> git 1 befehl + 0.1 sek ausführzeit.
>
> weil git weiß das es sich um ein branch handelt es merkt sich dann
> nur noch so ne art diff.
ok. zugegebenerweise vorteilhaft.
> du hast nicht git versionen, du hast einfach einen git ordner ein
> clone von dem repos, dort drin kannst du mit git branch alle branches
> anzeigen und mit git checkout branch zu dem gewünschten branch hin
> wechseln. Du kannst dann lokal schon mal vormergen, branches die auf
> dem Server vielleicht gar nie angelegt werden.
Schön und gut, um meinen eigenen Code von einem Arbeitstag zu
überblicken ist das vieleicht ganz nett. Das Problem ist doch nach
wie vor wenn mehrere Leute an einer Sache arbeiten und irgendwann der
Punkt kommt wo meine Änderungen und die der anderen zusammengeführt
werden. Das ist die gleiche Grütze wie bei svn, oder?
> > Das kann ich mit meinen svn Branches auch machen, und ich habe zum
> > Schluß genau das gleiche Problem mit Konflikten.
>
> nein wenn du 5 commits hast und daraus zuerst 10 machst und dann
> wieder 3 hast du keine conflikte da der code ja nie eingecheckt
> wurde.
Ich habe mit meinem eigenen Code ohnehin nie Konflikte und das nicht
eingecheckter Code nicht zu Konflikten führt ist ein Pseudoargument.
> also durch das aufteilen oder zusammenfügen und nachbearbeiten
> von commmits in git bekommst du keine probleme sofern du nicht schon
> eingecheckt hast, wenn doch solltest du es lassen wie es ist da man
> upstream nicht mehr in der history rum fummeln sollte in der regel.
> Aber du kannst sehr leicht noch deine commits nachbearbeiten wenn dir
> beim 5. commit auffällt das du beim commit 1 nen fehler gemacht hast,
> kein problem git rebase -i HEAD~5 (e setzen für edit bei dem commit)
> einfach das fixen wieder commiten git rebase --continue bist wieder
> bei HEAD. Mach das mal mit svn ^^ da wäre ein weiterer fix-commit
> fällig.
Keine Ahnung was du genau meinst, klingt für mich Git-Laien aber echt
kompliziert und nicht sonderlich spaßig.
> ach du meinst du hast überall ein lokalen server in den du jeweils
> eincheckst dann. Das ist dann hier aber ein overhead bei 2 pcs
> brauchst dann 2 server oder wenigstens 1 + 2 clients, bei git
> brauchst nur 2 clients.
Nein, ich habe einen zentralen Server und egal an welchen Rechner ich
mich setze, in wenigen Sekunden ist meine Working Copy auf dem
aktuellen Stand. Sprich: ich mache vor Feierabend einen Commit, mache
zuhause ein Update und bin in wenigen Sekunden wieder auf dem
aktuellen Stand.
> Und eben die geschwindigkeit, das verleitet einen
> auch eher kleinere patches zu machen, wenn man nur dei doku schnell
> ändern will ein wort in einer txt datei ändern will macht man dafür
> ein commit arbeitet weiter macht wieder commits. dann einmal push
> 5-10 commits übertragen. schaut sich die einzelnen diffs vorher noch
> an
>
> ob irgend ein mist drin ist.
>
> git grep ist sehr nützlich... uih siehst hätt wieder ein fehler
> gemacht es heißt nicht branch/... sondern branches/... jaja ein
> fehler der bei git unmöglich ist.
Sorry für die blöde Frage, aber hast du mal _richtig_ mit svn
gearbeitet?
> Meiner ansicht nach skaliert auch git deutlich besser, um so mehr
> leute an um so mehr branches arbeiten und um so größer die änderungen
> werden kann man es noch kleinteiliger unterteilen (lokale branches)
> auch kann man leichter verschiedene versionen von programmen
> verwalten git fetch repos-from-some-body-else sich dann die commits
> raus picken die man gut findet eventuell sogar commits noch
> nachbearbeiten dann integrieren. Ja man kann das meiste auch mit svn
Okay, drei Entwickler arbeiten an einem Projekt. Der erste pickt sich
Änderungen vom zweiten - der dritte bleibt außen vor. Wie kriegt man
jetzt die Arbeit von allen dreien wieder zusammen?
> Dann weiter ein Merge machst du erstmal lokal, wenns dir taugt und du
> sagst sieht gut aus pusht du es zu nem Server z.B. wenn du bei svn
> mist machst beim merge, legst damit den server lahm und alle müssen
> warten bis du es gefixt hast.
Feature Branch => in die Working Copy vom Trunk mergen => Testen =>
in den Trunk Committen
Keiner muss warten und selbst wenn man Mist committed kann man ja
immer noch reverten.
> > Merge => kein Konflikt => Super. Über den Fall brauchen wir hier echt
> > nicht zu diskutieren ;)
>
> Doch Zeit, wenn du jeden tag 100x Commitest und bei svn jeder Commit
> im schnitt 10 sekunden dauert sind das 1000 Sekunden -> sind das fast
> 30 Minuten.
Du willst mir nicht gerade wirklich weismachen, dass du alle 5
Minuten ein Commit machst?
> Ja man kann dort einfach mehr Falsch machen, wie gesagt das man ein
> Tag bearbeiten kann was ja eigentlich nicht sinnvoll ist, geht
> einfach mal nicht ohne ganz spezielle commandos.
Der Fehler passiert einem vieleicht ein oder zwei mal und nie wieder.
Außerdem kann es sehr wohl sinnvol sein einen Tag zu bearbeiten. Zum
Beispiel um mal eben einen wirklich dringenden Bugfix einzuspielen.
> Dann muss man bei nem merge wissen wenn man den Branch erzeugt hat
> bei welchem Commit, das sollte SVN eigentlich wissen tuts aber nicht.
Musst du nicht. Üblicherweise willst du ja einen fertigen Endstand
aus dem Branch auf den Hauptzweig zurückspielen.
> Und wie gesagt ein Branch erzeugen, dauert bei SVN oft sehr lang, bei
> git 1 befehl + 0.1 sek ausführzeit.
>
> weil git weiß das es sich um ein branch handelt es merkt sich dann
> nur noch so ne art diff.
ok. zugegebenerweise vorteilhaft.
> du hast nicht git versionen, du hast einfach einen git ordner ein
> clone von dem repos, dort drin kannst du mit git branch alle branches
> anzeigen und mit git checkout branch zu dem gewünschten branch hin
> wechseln. Du kannst dann lokal schon mal vormergen, branches die auf
> dem Server vielleicht gar nie angelegt werden.
Schön und gut, um meinen eigenen Code von einem Arbeitstag zu
überblicken ist das vieleicht ganz nett. Das Problem ist doch nach
wie vor wenn mehrere Leute an einer Sache arbeiten und irgendwann der
Punkt kommt wo meine Änderungen und die der anderen zusammengeführt
werden. Das ist die gleiche Grütze wie bei svn, oder?
> > Das kann ich mit meinen svn Branches auch machen, und ich habe zum
> > Schluß genau das gleiche Problem mit Konflikten.
>
> nein wenn du 5 commits hast und daraus zuerst 10 machst und dann
> wieder 3 hast du keine conflikte da der code ja nie eingecheckt
> wurde.
Ich habe mit meinem eigenen Code ohnehin nie Konflikte und das nicht
eingecheckter Code nicht zu Konflikten führt ist ein Pseudoargument.
> also durch das aufteilen oder zusammenfügen und nachbearbeiten
> von commmits in git bekommst du keine probleme sofern du nicht schon
> eingecheckt hast, wenn doch solltest du es lassen wie es ist da man
> upstream nicht mehr in der history rum fummeln sollte in der regel.
> Aber du kannst sehr leicht noch deine commits nachbearbeiten wenn dir
> beim 5. commit auffällt das du beim commit 1 nen fehler gemacht hast,
> kein problem git rebase -i HEAD~5 (e setzen für edit bei dem commit)
> einfach das fixen wieder commiten git rebase --continue bist wieder
> bei HEAD. Mach das mal mit svn ^^ da wäre ein weiterer fix-commit
> fällig.
Keine Ahnung was du genau meinst, klingt für mich Git-Laien aber echt
kompliziert und nicht sonderlich spaßig.
> ach du meinst du hast überall ein lokalen server in den du jeweils
> eincheckst dann. Das ist dann hier aber ein overhead bei 2 pcs
> brauchst dann 2 server oder wenigstens 1 + 2 clients, bei git
> brauchst nur 2 clients.
Nein, ich habe einen zentralen Server und egal an welchen Rechner ich
mich setze, in wenigen Sekunden ist meine Working Copy auf dem
aktuellen Stand. Sprich: ich mache vor Feierabend einen Commit, mache
zuhause ein Update und bin in wenigen Sekunden wieder auf dem
aktuellen Stand.
> Und eben die geschwindigkeit, das verleitet einen
> auch eher kleinere patches zu machen, wenn man nur dei doku schnell
> ändern will ein wort in einer txt datei ändern will macht man dafür
> ein commit arbeitet weiter macht wieder commits. dann einmal push
> 5-10 commits übertragen. schaut sich die einzelnen diffs vorher noch
> an
>
> ob irgend ein mist drin ist.
>
> git grep ist sehr nützlich... uih siehst hätt wieder ein fehler
> gemacht es heißt nicht branch/... sondern branches/... jaja ein
> fehler der bei git unmöglich ist.
Sorry für die blöde Frage, aber hast du mal _richtig_ mit svn
gearbeitet?
> Meiner ansicht nach skaliert auch git deutlich besser, um so mehr
> leute an um so mehr branches arbeiten und um so größer die änderungen
> werden kann man es noch kleinteiliger unterteilen (lokale branches)
> auch kann man leichter verschiedene versionen von programmen
> verwalten git fetch repos-from-some-body-else sich dann die commits
> raus picken die man gut findet eventuell sogar commits noch
> nachbearbeiten dann integrieren. Ja man kann das meiste auch mit svn
Okay, drei Entwickler arbeiten an einem Projekt. Der erste pickt sich
Änderungen vom zweiten - der dritte bleibt außen vor. Wie kriegt man
jetzt die Arbeit von allen dreien wieder zusammen?