Erfahrungen mit dem Einsatz von subversion

[eagle]

Ich wollte mal fragen wie Eure Erfahrungen bei der Nutzung von subversion sind. Wir setzen hier ein Rechner mit Debian etch und der subversion Version 1.4.2dfsg1-2 ein.

Leider kommt es teilweise vor, dass das Repository nach einem commit fehlerhaft ist. Das bedeutet, einige Dateien sind nicht der richtigen Version vorhanden oder teilweise verschwunden.

Dieses Verhalten ist m.E. bei einer Versionkontrolle nicht zu akzeptieren. Wie sind Eure Erfahren im produktiven Einsatz.

eagle

[hupfdule]

Also dass Dateien verschwunden sind, bzw. in der falschen Version vorlagen, hab ich noch nicht geschafft. Über was für einen Client greift ihr auf das Repository zu? Die Wahrscheinlichkeit ist hoch, dass diese evtl. Fehler machen. Insbesondere von subclipse habe ich derartiges gehört (jedoch noch nicht selbst erlebt).

Ich habe es schon mal geschafft mein Repository zu zerhauen, indem ich Dateien oberhalb eines Moduls eingecheckt hab. Wie ich das geschafft hab, weiß ich nicht mehr. Ich lege das mal als PEBKAC ab. Was mich auch gelegentlich verwirrt ist, dass die Verzeichnishierarchie trunk,tags,branches kein festes Konzept ist, sondern eine Konvention, die man selbst einhalten muss. Wenn man ein neues Modul ins Repository stellt und das vergisst, dann ärgert man sich erst mal.

Ich setze auf dem Server subversion aus sarge ein, clientseitig aus sid (Kommandozeilenclient), bzw. subclipse (genauere Versionen hab ich grad nicht zur Hand).

[armin]

Ich bin zwar definitiv kein Subversion-Fan mehr (wer braucht den Heutzutage noch ein zentrales CMS?), allerdings hatte ich bisher noch keine Porbleme derart. Weder mit Sarge, noch mit Etch.

[grb]

Hi, was meine Erfahrungen mit Subversion betrifft, nun, das sind eigentlich durchaus gute. Allerdings hat hupfdule recht, was Subclipse betrifft. Damit gibt es gelegentlich Ärger, hab es am eigenen Leibe erfahren müssen.

[Geisel Gangsta]

Ich persönlich habe bisher mit Subclipse nur gute Erfahrungen gemacht. Wir haben das an der Fachhochschule eingesetzt für ein Projekt an dem 5 Leute beteiligt waren.
Während des gesamten Nutzungszeitraums (etwa 3 Monate) gab es nur einmal ein Problem, welches aber durch falsche Bedienung eines Benutzers hervorgerufen wurde. Man sollte halt vor dem Commiten nochmal Updaten

[eagle]

Das beschriebene Problem konnte in mehreren Versuchen reproduziert werden. Sobald man versuchte eine größere Anzahl von Dateien (ca. 80) zu commiten, kam es zum Defekt.

Wenn weniger Dateien gleichzeitig "commited" wurden war alles in Ordnung.

In der Vergangenheit traten solche Probleme auch beim Commit von binären Dateien auf.

eagle

[Bert]

Hallo eagle,

was setzt ihr als FS Backend bei Subversion auf? wir hatten anfänglich Probleme mit dbd Backend, nach dem Umschaltem auf das FSFS eigentlich nicht mehr. Nach meinem Wissen ist bei der Debian Version FSFS der Standard.

Verwendet wird das Subversion von 20+ Leuten, ihn vielen Projekten, meine Nutzung (und ich denk auch die der Anderen) ist sicherlich eher auf ein commit einer kleinen Anzahl von Dateien aus.

Daten-'Verluste' hatte ich bisher nur durch Subclipse, hier sollte man immer die Syncronise Option verwenden, ein einfaches Commit scheint unter bestimmten Umständen einfach aktualisiertere Versionen zu überschreiben.

Trigger: wieso braucht mn heut kein zentrales CMS mehr? Im Firmenumfeld kann ich mir Darcs und Konsorten gar nicht vorstellen.

Gruß Bert

[eagle]

was setzt ihr als FS Backend bei Subversion auf? wir hatten anfänglich Probleme mit dbd Backend, nach dem Umschaltem auf das FSFS eigentlich nicht mehr. Nach meinem Wissen ist bei der Debian Version FSFS der Standard.

Meines ist es FSFS, wir hatten die Debian Standartinstallation genommen.

eagle