Subversion == totaler Schrott???
-
Subversion ist imo Schrott. Besser als *kein* VCS, aber immer noch Schrott.
Das Problem ist nicht unbedingt die grauenhafte Performance, die übertrieben großen Reposity-Folder oder das instabile TortoiseSVN.
Das größte Problem ist meiner Meinung nach, dass man so leicht Fehler machen kann und so sein Repository ganz leicht unbrauchbar machen kann. Mal eben nen Ordner in der IDE ohne VCS renamed, ne neue Date erstellt und ne alte geändert? Viel Spaß beim Committing - und noch mehr Spaß beim anschließenden merging des manuell hergestellten Sourcetrees mit dem neuen Code.
Mein Favorit ist ja ein Eclipse Java Projekt + SVN. Warum? Im .eclipse Folder werden immer neue Files hinzugefügt (und gelöscht) und die Class-Dateien sind ja erstmal auch alle im SVN. Ein simples commit - Feierabend geht in so einem Setup prinzipiell nicht.
Eine gute Alternative scheint Git zu sein (nman Fragen
- habe ich aber noch nicht getestet.
-
Einige der Probleme mit Subversion sind auch BDB-spezifischer Natur. Wenn Du bei Subversion mal in den Sourcen herumgewühlt hast, wird Dir ganz schnell übel.
Könnte sein, dass das mit FSFS besser ist, ich persönlich habe das nie ernsthaft ausprobiert, weil es noch viel zu wackelig war, als ich noch Subversion verwendete, aber vielleicht hilft es Dir in diesem Fall ja sogar.
-
Ishildur schrieb:
Danach sämtliche Projektdaten vom Datenserver in dieses Verzeichnis kopiert (dieses Projekt war bisher nicht versioniert) (ca. 2.18 GB), danach wieder Rechtsklick auf das Verzeichnis->SVN Commit...
So wie Du es da beschreibst fehlt der Schritt SVN.Add vor dem SVN.Commit
-
loks schrieb:
Ishildur schrieb:
Danach sämtliche Projektdaten vom Datenserver in dieses Verzeichnis kopiert (dieses Projekt war bisher nicht versioniert) (ca. 2.18 GB), danach wieder Rechtsklick auf das Verzeichnis->SVN Commit...
So wie Du es da beschreibst fehlt der Schritt SVN.Add vor dem SVN.Commit
Mit TortoiseSVN kann man sich den extra "add" Schritt sparen, und stattdessen direkt im Commit-Dialog machen.
-
Hab immer mal wieder dieselben Probleme mit SVN (Vista + SmartSVN). Ab und an bekommt der client nen rappel und plötzlich sind überall Konlikte, phantom files, nicht passende revisions, was nicht alles. Da hilft dann manchmal nur noch die Große revert-Kelle.
Hab bislang aber noch kein version control system gefunden, dass mit "normaler" Arbeitsweise (z.B. manuelles Verschieben von Dateien) klaglos zurechtkommt. Damit ist spätestens bei mittelgroßen Projekten schluss.
-
subversion21 schrieb:
Hab bislang aber noch kein version control system gefunden, dass mit "normaler" Arbeitsweise (z.B. manuelles Verschieben von Dateien) klaglos zurechtkommt. Damit ist spätestens bei mittelgroßen Projekten schluss.
TFS kann das problemlos
-
Zwischenfrage: Ist TFS eine Art Maven + VCS für das Visual Studio?
MfG SideWinder
-
Was SVN und Studio-Integration angeht, kann ich VisualSVN empfehlen. Ich nenne dauernd Files im Visual Studio um, lösche welche oder füge neue hinzu. VisualSVN kümmert sich dabei verlässlich darum das Nötige in der SVN Working-Copy zu tun.
-
Hi
Kann da hustbaer nur zustimmen. VisualSVN ist top !
Gruss lowbyte
-
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 $ 
