Source- Versionskontrolle

nman

berkeleydb-freak schrieb:

nman schrieb:

Subversion ist in solchen Fällen insbesondere aufgrund des Berkeley-Backends nicht günstig...

was ist daran nicht günstig? erzähl mal genauer...

Ganz einfach, Berkeley-DBs sind äußerst anfällig für Korruption, darum vertraue ich ihnen ungern Daten an.

(Und ich spreche hierbei noch nichtmal von Stromausfällen, Netzwerkunterbrechungen oä. Schon Programme, die ihre Verbindungen nicht sauber beenden udgl. hinterlassen die DB in vielen Fällen in einem inkonsistenten Zustand.)

pointercrash**

rüdiger schrieb:

Ich würde dir ein dezentrales Versionskontrollsystem - wie git, Monotone oder Mercurial - empfehlen.

Stimme dem zu - Subversion bedeutete erstmal einen großen Installationsaufwand mit lauter Zeug, das ich sonst nicht brauche.
Ich probiere gerade Monotone aus, es geht zwar, aber durch die Kommandozeilengeschichte ist das fürchterlich viel Tipperei, mal sehen, ob Monotree da hilft.
Aber genau so eine kleine, lokale Sache hab' ich mir vorgestellt - Danke erstmal!

tfa

Wer benutzt denn Subversion noch mit Berkeley-DB? Seit knapp 4 Jahren wird doch fsfs unterstützt.

hustbaer

blah.

mir wäre ein ordentliches SQL backend für SVN auch lieber, aber dass BDB so anfällig sein soll, das sind schauergeschichten von grossmutter raumfalte.

ja, es kann vorkommen dass eine BDB datenbank "recovert" werden muss wenn ein programm abgeschmiert ist, was aber genau dasselbe ist wie das was jeder datenbank server beim starten macht: die letzten paar transaktionen im logfile durchackern und committen bzw. rollback machen.

subversion 1.4 kann das im übrigen auch schon länger automatisch erledigen.

@rüdiger: wenn ein server stirbt hat man backups

hustbaer

tfa schrieb:

Wer benutzt denn Subversion noch mit Berkeley-DB? Seit knapp 4 Jahren wird doch fsfs unterstützt.

WIR

nman

tfa schrieb:

Wer benutzt denn Subversion noch mit Berkeley-DB? Seit knapp 4 Jahren wird doch fsfs unterstützt.

Stimmt. Das ist zwar auch Käse, hat dafür aber wenigstens ganz andere Probleme als Berkeley-DB. Dummerweise lassen sich die Repositories immer noch verdammt leicht korrumpieren, mir sind auch FSFS schon ohne Zugriffe von außen (nur via svn-Client) kaputt gegangen. Und da ist dann meistens Handarbeit angesagt wenn nicht irgendwas völlig triviales passiert ist.

Herrmann

Wir verwenden hier auf Arbeit Subversion. Und auch zu Hause hab ich einen Subversion-Server stehen. Vielleicht sind andere Systeme besser (kenne nur SourceSafe,CVS und Subversion) aber für meine Zwecke reicht es.

nman

hustbaer schrieb:

mir wäre ein ordentliches SQL backend für SVN auch lieber, aber dass BDB so anfällig sein soll, das sind schauergeschichten von grossmutter raumfalte.

Nichts für ungut, aber nur weil Du noch keine Probleme damit hattest, heißt das noch lange nicht, dass es keine gibt.

@rüdiger: wenn ein server stirbt hat man backups

Wunderbarerweise brauchen aber die Entwickler mit verteilten VCS nichtmal darauf warten, dass der Server wieder erreichbar ist, sondern können einfach ganz normal weiterarbeiten.

pointercrash**

Hallo zusammen nochmal,

Monotree ist nur ein Viewer und das Getippsel bei monotone macht mich wahnsinnig . Gibt's da wirklich nichts, was auch mit einer freundlichen GUI daherkommt und nicht so "fett" ist, wie Subversion?

pointercrash**

hustbaer schrieb:

@rüdiger: wenn ein server stirbt hat man backups

So, und wie weit reichen die zurück? Bei mir stand ein zugegebenermaßen betagtes System, dessen Datenbank inkonsistent wurde, das war wohl schon längere Zeit so, die hat sich so nach und nach die Rollbacks zerlegt. Eine Woche Backup hilft da auch nichts mehr und wenn die letzte DVD auch einen Schuß hat, was will ich mit vier Monate alten Rollbacks auf der vorletzten Vollsicherung?

Ging nicht anders, hab' die Sourcen halt auf dem letzten Stand rausgezogen und auf die Rollbacks gepfiffen.

simon.gysi

Eine Woche Backup hilft da auch nichts mehr

Ein anständiger Admin backupt jeden Tag.

pointercrash**

simon.gysi schrieb:

Eine Woche Backup hilft da auch nichts mehr

Ein anständiger Admin backupt jeden Tag.

Mißverständnis: Klar jeden Tag. Ich mache ein wöchentliches Vollbackup HD2HD, täglich differentiell dazu, dann wird das Archiv überschreibend auf einen anderen Rechner umkopiert - und von da aus sporadisch auf DVD gebrannt.
Heißt, ich habe im ungünstigsten Fall eine Woche im Direktzugriff - und das hilft Dir gar nichts mehr, wenn die DB seit drei Wochen Käse baut. :p

.filmor

Für Mercurial gibt's TortoiseHG, für git git-cheetah. Hab ich aber beides nicht ausprobiert, mir reicht Kommandozeilen git bzw. das (unglaublich hässliche ;)) Tk-Interface git-gui.

Bashar

.filmor schrieb:

Für Mercurial gibt's TortoiseHG, [...]Hab ich aber [...] nicht ausprobiert

Zumindest unter Windows performancetechnisch eine Zumutung.

Ich schließe mich rüdiger an. *schleim*

Prof84

subversion-freak schrieb:

Prof84 schrieb:

Wir verwenden PLM!

ist bestimmt so toll wie alles andere von SAP auch

Hey, wir haben Aschermittwoch. Karneval is vorbei!

http://en.wikipedia.org/wiki/Product_Lifecycle_Management
http://en.wikipedia.org/wiki/Release_Management

Obwohl dort steht auch zugegeben eine Menge unwichter Kramm.
Das lässt sich alles auf simple Metamodelle zusammenfassen ...

Artchi

Ich kann euch sagen was ihr NICHT einsetzen solltet: Telelogic SYNERGY/CM.

DAS Dreckstool schlecht hin! Wir müssen es leider benutzen.

Für mich lesen sich die Wiki-Artikel ungefähr so *BUZZWORD* *blabla* *BUZZWORD* *BUZZWORD* *blablabla* *BUZZWORD* *BUZZWORD* *BUZZWORD* ...

Prof84

Artchi schrieb:

Ich kann euch sagen was ihr NICHT einsetzen solltet: Telelogic SYNERGY/CM.

DAS Dreckstool schlecht hin! Wir müssen es leider benutzen.

Bestätigt!

Ich musste vor 3 Jahren mal ein Team bei Siemens betreuen, dass dieses Tool pilotieren musste. Die sind ratzfatz zu ClearCase/ClearQuest geswitched! Zumal dies Tool kompatibell zu DOORS/ERS war. Apropos CVS, PVCS war dort noch im Einsatz ...

Was auch die Hölle war: Caliber von Borland.

git hat den vorteil lokaler commits, sodass man ein persönliches repository haben kann. der nachteil ist, dass es, zumindest in meinen augen, weitaus komplizierter ist als subversion. trotzdem verwend ich es.
an der uni hatten wir subversion, aber die leute waren eh alle zu dumm, um ein vcs richtig zu verwenden und haben andauernd im code des anderen herumgepfuscht, sodass fast jeder commit zu konflikten geführt hat. man muss ein vcs auch richtig verwenden können.

Buzzer schrieb:

Für mich lesen sich die Wiki-Artikel ungefähr so *BUZZWORD* *blabla* *BUZZWORD* *BUZZWORD* *blablabla* *BUZZWORD* *BUZZWORD* *BUZZWORD* ...

es geht hier um software entwicklung. was erwartest du anderes? die welt is halt einfach schlecht