Welches Version Control System?
-
xaver02 schrieb:
Wenn man einmal Tortoise SVN gewohnt ist, will man nie wieder mit der Konsolen-Version arbeiten.
ich benutze zwar auch tortoise-svn, hätte's aber lieber als separate anwendung und nicht als shell-extension. weiss wer ob es da was gescheites gibt?
-
SVN-Freak schrieb:
xaver02 schrieb:
Wenn man einmal Tortoise SVN gewohnt ist, will man nie wieder mit der Konsolen-Version arbeiten.
ich benutze zwar auch tortoise-svn, hätte's aber lieber als separate anwendung und nicht als shell-extension. weiss wer ob es da was gescheites gibt?
SmartSVN ist in der Foundation Version kostenlos und ganz brauchbar.
-
xaver02 schrieb:
SmartSVN ist in der Foundation Version kostenlos und ganz brauchbar.
danke. sieht gut aus...
-
dEUs schrieb:
@rüdiger:
als SVN-Fan dem die Schwächen durchaus bekannt sind: Kannst du in 2, 3 Sätzen skizieren, wie git die Problematik beim Branching und vor allem Merging löst?noch besser. Ich verweise dich gleich mal auf den Git-Crash-Course für SVN-Fans http://git.or.cz/course/svn.html#merge Branching ist auch nur eine Anweisung. Ähnlich bei Monotone.
@xaver02
Da kenne ich mich nicht genau aus, da ich git/monotone Plugins für meine IDE nehme und sonst auch mit der Konsolen-Version glücklich bin. Aber für viele IDEs gibt es entsprechende Plugins.
-
Hi Rüdiger,
also doch nicht so toll wie es bei dir geklungen hat
Der einzige Unterschied ist, dass git sich vorherige Merges automatisch merkt was man bei SVN noch manuell machen muss.
Alles andere ist gleich.
Auch Branching ist in SVN nur eine einfache Operation: Ein Copy
-
Naja, die History wird halt auch nicht gemergt und du musst dich um Dinge manuell kümmern.
-
dEUs schrieb:
Auch Branching ist in SVN nur eine einfache Operation: Ein Copy
Subversion talks very loudly about how they do CVS right by making branching really cheap. Even if it takes a millionth of a second to do branching: Who cares? It's the wrong thing you're measuring. Nobody is interested in branching. Branches are completely useless until you merge them. And CVS cannot merge anything at all. You can merge things once, but because CVS then forgets what you did, you can never ever merge anything again without getting horrible horrible conflicts. Merging in Subversion is a complete disaster. The Subversion people kind of acknowledge this and they have a plan and their plan s*cks, too. It is incredible how stupid these people are. They've been looking at the wrong problem all the time. Branching is not the issue, merging is. And merging they do dreadful, five years after the facts. That is sad.
:xmas1:
-
Linus T. schrieb:
dEUs schrieb:
Auch Branching ist in SVN nur eine einfache Operation: Ein Copy
Subversion talks very loudly about how they do CVS right by making branching really cheap. Even if it takes a millionth of a second to do branching: Who cares? It's the wrong thing you're measuring. Nobody is interested in branching. Branches are completely useless until you merge them. And CVS cannot merge anything at all. You can merge things once, but because CVS then forgets what you did, you can never ever merge anything again without getting horrible horrible conflicts. Merging in Subversion is a complete disaster. The Subversion people kind of acknowledge this and they have a plan and their plan s*cks, too. It is incredible how stupid these people are. They've been looking at the wrong problem all the time. Branching is not the issue, merging is. And merging they do dreadful, five years after the facts. That is sad.
:xmas1:Koennter den Link nochmal posten? Wuerds mir gern durchlesen.
-
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.