Welches Version Control System?
-
DEvent schrieb:
Koennter den Link nochmal posten? Wuerds mir gern durchlesen.
-
hab irgendwie meine zweifel, dass merging mit git problemlos über die bühne geht. aber lass mich ja gern vom gegenteil überzeugen
der gedanke ans merging bereitet mir jedesmal kopfschmerzen, wenn ich nen branch anlege.
-
alle verteilten vcs's managen merging einfach nur toll
u.a. weil es absolut notwendig ist, da es durch die verteilte natur ständig zu microbranches/merges kommt, da die entwickler nebeneinander arbeiten
ich halte git, monotone, mercurial und darcs für empfehlenswert
ich selber habe inzwischen eine vorliebe für mercurial entwickelt
-
micro merges sind für mich nicht interessant. merges auf file basis bekommt sogar cvs ganz gut gebacken. aber wenn zwei branches gemerged werden müssen, die wochen oder sogar monate auseinandergelaufen sind, dann wirds eklig. und das kommt leider häufiger vor, als einem lieb ist.
-
zwei textfiles zu mergen ist ja nicht so'n grosses problem, nur wenn es sich dabei um code handelt, ist es fraglich, ob das resultat danach noch lauffähig ist, und wenn ja, würde alle alarmglocken klingeln. beim code mergen würde ich das ergebnis jedenfalls ganz genau unter die lupe nehmen.
-
code wird bei jedem check-in merged
und wenn man da nicht grad wild im code rumgewühlt hat, geht das auch meist konflikt- und problemfrei über die bühne.aber wenn in dateien viel rumgewühlt wurde, dann schlagen merges häufig dramatisch fehl. der geilste fehler, den wir mal hatten, waren code-zeilen verdoppelungen. erstklassig. syntax 1A, semantik im arsch ^^
hat torvalds schon korrekt erkannt. was nen VCS anständig können muss ist merging. alles andere ist nebensache.
-
thordk schrieb:
hat torvalds schon korrekt erkannt. was nen VCS anständig können muss ist merging. alles andere ist nebensache.
nö, er sieht das komplett verkehrt. ein vcs kann niemals so intelligent code mergen wie ein mensch, aber wenn man modular programmiert, muss es das auch nicht.
-
klar kann es das nicht. aber was will man dann als kernmerkmal eines VCS herausstellen? ohne merging ist ein VCS nichts anderes als ein backup.
-
rüdiger schrieb:
DEvent schrieb:
Koennter den Link nochmal posten? Wuerds mir gern durchlesen.
Danke.
Git ist ja einfach cool. Habs gestern ausprobiert und es fuehlt sich besser als SVN an. Vor allem das Branchen/Mergen ist ja kinderleicht. Ich hatte bis jetzt fuer meine privaten Projekte SVN benutzt mit einem USB-Stick als "Server". Den Stick konnte ich so ueberall mitnehmen und ueberall aus-checken.
-
thordk schrieb:
klar kann es das nicht. aber was will man dann als kernmerkmal eines VCS herausstellen? ohne merging ist ein VCS nichts anderes als ein backup.
Ich wueder das nicht unterschaetzen. Ein gutes inkrementielles Backup mit Logs und History, dazu noch speichersparend (weil nur die Aenderungen im Backup sind) und mit einfacher Wiederherstellung eines commit.
Aber wie soll den bitte ein VCS so intelligend wie ein Mensch Code mergen koennen? Wenn man modulisiert Arbeitet ueber Schnittstellen dann bracht man eigentlich sowas auch nicht.
-
thordk schrieb:
aber was will man dann als kernmerkmal eines VCS herausstellen?
naja, z.b. bei git, dass es ohne zentrales repository arbeitet. das ist ja schon mal komplett anders als bei traditionellen vcs's. welche vor- und nachteile so eine architektur mit sich bringt, ist erstmal egal. man kann aber mindestens damit angeben, dass es 'anders' ist.
-
git ist ja echt gut, grade ein branch ueber laengere Zeit bearbeitet (2 Tage), zwischendurch den master branch geaendert (ein paar kleine Fehler behoben) und dann den branch gemergt.
39 files changed, 1805 insertions(+), 1522 deletions(-)
Das ganze automatisch ohne einen einzigen Konflikt.