3. Subversion == totaler Schrott???

Subversion == totaler Schrott???

  • S

    @Ishildur: Für binäre Dateien sind diese VC-Systeme aber afaik alle nicht wirklich geeignet.

    Ganz abgesehen davon hatte ich auch immer solche Probleme mit Subversion bei größeren Projekten (vor allem Refactoring (= Verschibeen & Umbenennen) hat immer ganz furchtbare Probleme ausgelöst). Ich bin jetzt auf Grund meiner Universität auf Mercurial umgestiegen und bin bis jetzt sehr zufrieden. Habe das erste größere Projekt ganz ohne eine einzige Fehlermeldung durchgeführt. Und wir haben exzessiv gelöscht/umgebaut.

    (Mangels IDE-Unterstützung fehlt uns aber wie bei CVS die Historie falls die Datei umbenennt wurde...)

    MfG SideWinder

    0
  • I

    @ich bins
    Desshalb habe es ja als Frage gestellt? 😉
    Und "User == keine Ahnung", dann sag mir doch jetzt bitte, was ich anstatt Commit machen muss? Ich mache Update, Commit, Reverse und CleanUp. Jede dieser Funktionen verursacht Fehler beim aktuellen Projekt. Ist das wirkliche Versagen des Users?

    0
  • ?

    Dann also:

    Nein, SVN nix totaler schrott. Arbeite damit seit geraumer Zeit, so gut wie keine probleme bisher. Man muss allerdings durchaus das eine oder andere beachten, besonders beim mergen.

    Allerdings habe ich auch schon gehört, dass ab 2GB SVN kritisch wird. Aber mit ~1,5GB hatte ich noch keine probleme, das waren auch deutlich mehr als mickrige 1500 dateien.

    0
  • S

    Ishildur schrieb:

    @ich bins
    Desshalb habe es ja als Frage gestellt? 😉
    Und "User == keine Ahnung", dann sag mir doch jetzt bitte, was ich anstatt Commit machen muss? Ich mache Update, Commit, Reverse und CleanUp. Jede dieser Funktionen verursacht Fehler beim aktuellen Projekt. Ist das wirkliche Versagen des Users?

    Was passiert wenn du svn direkt verwendest? Kommen dann die selben Fehler?

    0
  • I

    @KuhTee

    das waren auch deutlich mehr als mickrige 1500 dateien.

    Hast du aber auch mal versucht, alle deine Dateien auf einmal zu committen?
    Also ich erkläre noch einmal die Situation bei mir jtzt gerade.

    Ich habe eine leeres Repository auf meinem FreeBSD Server im Keller gemacht svnadmin create Serenity
    chown -R www:www Serenity

    Danach auf der Win7 Kiste mit Tortoise 1.6.9 (heute heruntergeladen und installiert), ein neues Verzeichnis auf Desktop erstellt. Danach Rechtsklick->SVN Checkout...
    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...

    Augenblicklich erscheint eine Fehlermeldung:
    Can't move... ...Die Datei oder das Verzeichnis ist nicht lesbar

    Ich klicke OK und mache gleich noch einmal ein commit. Jetzt funktionierts und er beginnt mit dem effektiven Datentransfer. Nach ca. 5min kommt:

    Commit succeeded, but other errors follow.
    Error bumping revision post-commit (details follow)... ... Error processing command.

    Ich sehe auch mit Hilfe von Windows Debugging Tools das einfach noch ca. 1000 Filelocks auf Tortoise offen sind, obwohl Tortoise längst beendet wurde (CreateFile ohne CloseHandle). Und tatsächlich, jeder weitere Versuch von Commit und CleanUp endet mit der Fehlermeldung von Tortoise:

    Working Copy... ...Locked. Please execute CleanUp Command
    CleanUp failed, Working Copy locked.

    Und das selbst nach einem Neustart des Rechners...

    0
  • I

    @Shade Of Mine
    Was meinst du mit "direkt verwendest"? Irgend einen Client benötige ich doch?

    0
  • ?

    nein du brauchst keinen client wie tortoise, einfach mal so svn verwenden - über die kommandozeile.
    git wäre vielleicht auch mal einen blick wert 😉

    0
  • B

    Ishildur schrieb:

    @KuhTee
    Hast du aber auch mal versucht, alle deine Dateien auf einmal zu committen?
    Also ich erkläre noch einmal die Situation bei mir jtzt gerade.

    Ich habe eine leeres Repository auf meinem FreeBSD Server im Keller gemacht svnadmin create Serenity
    chown -R www:www Serenity

    Danach auf der Win7 Kiste mit Tortoise 1.6.9 (heute heruntergeladen und installiert), ein neues Verzeichnis auf Desktop erstellt. Danach Rechtsklick->SVN Checkout...
    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...

    Augenblicklich erscheint eine Fehlermeldung:
    Can't move... ...Die Datei oder das Verzeichnis ist nicht lesbar

    Ich klicke OK und mache gleich noch einmal ein commit. Jetzt funktionierts und er beginnt mit dem effektiven Datentransfer. Nach ca. 5min kommt:

    Commit succeeded, but other errors follow.
    Error bumping revision post-commit (details follow)... ... Error processing command.

    Ich sehe auch mit Hilfe von Windows Debugging Tools das einfach noch ca. 1000 Filelocks auf Tortoise offen sind, obwohl Tortoise längst beendet wurde (CreateFile ohne CloseHandle). Und tatsächlich, jeder weitere Versuch von Commit und CleanUp endet mit der Fehlermeldung von Tortoise:

    Working Copy... ...Locked. Please execute CleanUp Command
    CleanUp failed, Working Copy locked.

    Und das selbst nach einem Neustart des Rechners...

    OT: cool dass deine Kiste Serenity heisst 👍 Firefly-Fan?

    0

  • Ich glaub sein Repository heisst Serenity.
    Und ich schätze das wird der Name eines Spiels sein (er hat ja Texturen & Meshes erwähnt).

    0
  • ?

    Schonmal dran gedacht das dein Computer im Arsch drinne sein könnte? :schland:

    0
  • H

    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.

    0
  • N

    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.

    0
  • ?

    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

    0

  • 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.

    0
  • ?

    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.

    0
  • E

    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 😉

    0
  • S

    Zwischenfrage: Ist TFS eine Art Maven + VCS für das Visual Studio?

    MfG SideWinder

    0

  • 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.

    0
  • L

    Hi

    Kann da hustbaer nur zustimmen. VisualSVN ist top !

    Gruss lowbyte

    0
  • ?

    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.

    0
Anmelden zum Antworten