Welches Version Control System?
-
bazaar
-
Termite schrieb:
der klient ist hin und wieder etwas träge
Man könnte auch arschlangsam sagen. Der Server übrigens auch.
Arbeiten mit bei extrem grossen Projekten ( 1 GB / 10k - 15k files ) ist etwas langsam Checkpoint dauert fast ne ewigkeit in der man die Kolegen blockiert.
Korrekt.
- File rename und move bei erhalt der history
- Teilprojekte als shared subprojeckt in anderen Projekten einbinden ( libs, ... )
- ChangepackagesIch kenn mich mit CVS oder SVN gar nicht aus, aber ist es das wert? Ich mein wirklich? Nebenbei gesagt hab ich mir gestern den Vortrag von Linus, den hier jemand verlinkt hat, angesehen, und bin jetzt nicht so ganz überzeugt, dass CVS der Maßstab sein sollte.
und noch nen vorteil.
Einen Deutschsprachigen support den man anrufen kann.Es würde mich wundern, wenn der Support von denen noch kein Büro bei uns hat
-
rüdiger schrieb:
Ich würde dir git oder Monotone empfehlen
Wer installiert freiwillig ein Versionskontrollsystem das erst in der Version 0.3X ist?
-
xaver02 schrieb:
rüdiger schrieb:
Ich würde dir git oder Monotone empfehlen
Wer installiert freiwillig ein Versionskontrollsystem das erst in der Version 0.3X ist?
ich
"The latest stable Git release is v1.5.3.7"
-
@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?
-
Das Problem bei den verteilten VCS ist, dass es keine gute Lösung für Windows gibt. Wenn man einmal Tortoise SVN gewohnt ist, will man nie wieder mit der Konsolen-Version arbeiten. Die restlichen GUIs für bazaar oder git sind schlecht.
-
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.