Subversion == totaler Schrott???
-
Ja, SVN ist Schrott. Es gibt manchmal völlig grundlose Fehlermeldungen, die meisten von Ishildur kenne ich selber bereits.
Wenn euch das schon auf die Palme bringt, dann versucht wirklich nie nie nie nie nie mit SVN im Team zu arbeiten. Das ganze branchen und mergen ist einziger Bughaufen. Man muss sich selber die revisionen zum mergen aufschreiben, weil das merge tracking völlig unbrauchbar ist. Ich hatte schon Situationen, wo jede einzelne Datei conflicted war, auch Dateien die seit nem halben Jahr keiner angefasst hat. Ich hatte Konflikte, wo left und right völlig gleich war, aufs Byte genau. SVN merkt sich nach dem merge nicht, wer welche Änderung gemacht hat (dazu muss man in den Branch zurückgehen). Usw.!
Übrigens offizielle Aussage der Entwickler:
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html schrieb:
The bottom line is that Subversion's merge-tracking feature has an extremely complex internal implementation, and the svn:mergeinfo property is the only window the user has into the machinery. Because the feature is relatively new, a numbers of edge cases and possible unexpected behaviors may pop up.
For example, sometimes mergeinfo will be generated when running a simple svn copy or svn move command. Sometimes mergeinfo will appear on files that you didn't expect to be touched by an operation. Sometimes mergeinfo won't be generated at all, when you expect it to. Furthermore, the management of mergeinfo metadata has a whole set of taxonomies and behaviors around it, such as “explicit” versus “implicit” mergeinfo, “operative” versus “inoperative” revisions, specific mechanisms of mergeinfo “elision,” and even “inheritance” from parent to child directories.
(weiter unten werden workarounds präsentiert, die auch keine Abhilfe schaffen, wie zum Beispiel immer den gesamten Tree zu mergen)
Das ist in meinen Augen noch geschönt. Das ganze merge tracking ist Schrott, weil es nachträglich reingefrickelt wurde und auf Kompatibilität bedacht war. Da kann man sich an einer Hand abzählen, dass daraus auch nichts mehr wird. Die Dominanz von SVN auf dem Markt der zentralen Revisionskontrollsysteme ist mir völlig unverständlich.
-
@Optimizer: Das war doch auch zu Zeiten von CVS so. Wird ja auch nur noch ein paar Jahre so sein. Bis dahin wird es schon wieder etwas neues geben und niemand wird verstehen wie man überhaupt nur git verwenden konnte...
MfG SideWinder
-
nö, besser als git geht es nicht mehr.
-
Side: Das stimmt so nicht. CVS war eine furchtbare Krücke, die in Sachen Usability enorme Probleme hatte, aber es war immer robuster als Subversion und die Repos waren auch um Größenordnungen kompakter, was bei größeren Projekten nicht uninteressant ist.
flasch: Das würde ich jetzt nicht sagen, auch bei Git gibt es noch Verbesserungspotential, allerdings arbeiten daran und damit so viele Leute, dass ich zuversichtlich bin, dass das Entwicklungstempo sehr hoch bleiben wird.
Der Sprung hin zu verteilten Versionskontrollsystemen ist schon was äußerst wichtiges; Git ist eine größere Änderung als nur das Subversion des Tages. Subversion hatte immer schon riesige Schwierigkeiten, die wir allerdings alle gerne ignoriert haben, weil es ein paar lästige Fehler von CVS ausmerzte, sich aber sonst ziemlich ähnlich verhielt und man kein bisschen umdenken bzw. umlernen musste.
Wenn ich allerdings an Monotone, darcs und sonstige verteilte VCS, die ich verwendet habe, zurückdenke (BitKeeper sah auch recht nett aus), dann erinnere ich mich an Features, die nicht gepasst haben, fehlten oder viel zu kompliziert waren. Nicht daran, dass mich die jeweiligen VCS effektiv beim Arbeiten ausgebremst haben und ich immer wieder Angst um meine Daten haben musste. Nur massentauglich waren die meisten dezentralisierten VCS nicht so richtig, Git (und im soziodynamischen Fahrwasser davon Mercurial) ist einfach das erste wirklich weitverbreitete dezentralisierte VCS.
Und Git ist natürlich toll, aber wenn darcs robuster wäre, besser mit der Repogröße nach oben skalieren würde und brauchbaren Support für Symlinks hätte, würde ich das vielleicht tatsächlich noch verwenden und wäre auch recht glücklich damit.
Bazaar zB. finde ich jetzt nicht mehr allzu spannend (weil es ja Mercurial und Git gibt), aber prinzipiell hätte das durchaus auch Potential gehabt und wäre bestimmt ebenso gut verwendbar gewesen, nur war es vor Canonical eben viel schlechter dokumentiert und aufpoliert. Wenn die Kollegen früher dran gewesen wären, wäre vielleicht vieles anders abgelaufen.
-
Bazaar ist aber auch so ne ungute Mischung aus verteiltem VCS und man kann doch ein bisschen SVN-ähnlich arbeiten. Und es ist nicht so einfach, dass ein Affe es bedienen kann. Beim branchen hat man erstmal die Wahl zwischen 4 verschiedenen Arten von branches (wtf ist ein colocated branch?), ab da hab ich dann ziemlich schnell Mercurial ins Auge gefasst. Klar, es wird schon ein bisschen was taugen und ich hab mir nicht viel Mühe damit gegeben.
Aber das sollte auch nicht nötig sein. Meiner Meinung nach ist Bazaar an der Komplexität "gescheitert" (ich übertreib's jetzt mal).
-
Mir kam Bazaar auch immer unnötig kompliziert vor, aber das lag zu einem guten Teil auch an der miesen Doku und der schlechten Aufbereitung sämtlicher Ressourcen dazu. Wenn die paar typischen Use-Cases zugänglicher dokumentiert gewesen wären, dann hätte Bazaar durchaus erfolgreicher sein können, als es war.
-
@Alle
Hehe, OK, SVN ist für uns glaub ich abgehackt, was für Alternativen könnt Ihr denn empfehlen? Was haltet Ihr von Alienbrain?
-
Ishildur schrieb:
Was haltet Ihr von Alienbrain?
das ja mal richtig teuer
-
-
Alienbrain? schrieb:
Ishildur schrieb:
Was haltet Ihr von Alienbrain?
das ja mal richtig teuer
Ishildur schrieb:
http://www.alienbrain.com/pricing
32$ ?
schon klar in der schweiz gehen die uhren anders... da sind 30.000 gleich mal billig... schweizer müsst ich sein
-
Hehe, so anders ticken die Uhren in der Schweiz nicht, glaub mir
Ich dachte es während 32.00 $ und nicht 32'000 $ 
-
Was ist mit Perforce?
-
.
-
git für den Source Code und rsync für die Mediendateien?
-
Hmm und somit das Projekt in zwei Datenbanken aufteilen? Mit diesem Gedanken kann ich mich wahrlich nur schlecht anfreunden...
@hustbaer
.?
-
Ishildur schrieb:
Hmm und somit das Projekt in zwei Datenbanken aufteilen? Mit diesem Gedanken kann ich mich wahrlich nur schlecht anfreunden...
Naja, du kannst zwar auch alles in Git packen, aber das mag große Dateien nicht so sehr. Dann hast du nämlich wieder deine abendlichen Gigabyte-Transfers usw.
Außerdem hat das den Vorteil, keine 32000 $ zu kosten.
-
Was sind die Vor- resp. Nachteile von Git gegenüber Perforce?
-
Ishildur schrieb:
@hustbaer
.?Ich hatte ein Wort überlesen und dann voreilig Mist geschrieben
Da man Beiträge nicht löschen kann -> "."
-
Ishildur schrieb:
Was sind die Vor- resp. Nachteile von Git gegenüber Perforce?
Würde ich dir gerne ausführlich erklären. Leider kenne ich Perforce aber nicht.
-
Ishildur schrieb:
Was sind die Vor- resp. Nachteile von Git gegenüber Perforce?
http://whygitisbetterthanx.com/
+ git ist kostenlosAber ich würde für große Binärdateien auch eher rsync anstelle git oder andere Software VCS benutzen. Die sind ja idR nicht auf so etwas ausgelegt.
