Source- Versionskontrolle
-
Hi,
wir verwenden subversion.
Gruß mcr
-
Ich würde dir ein dezentrales Versionskontrollsystem - wie git, Monotone oder Mercurial - empfehlen. Gerade wenn du bereits erlebt hast, wie ein Server "stirbt", wirst du die Gefahren eines zentralen Systems kennen.
-
Subversion ist in solchen Fällen insbesondere aufgrund des Berkeley-Backends nicht günstig, auch wenn es viele Leute verwenden. Schließe mich ruediger an.
-
Wir verwenden PLM!
Ein enfacher Entwickler hat hier auf das Versionenmanagement keinen Einfluss
(ca. 1.000 SW-Entwickler). Übernehmen alles die Anforderungs- und Release- Manager.
Jedenfalls ist es mein Job dafür zu sorgen ...
-
Prof84 schrieb:
Wir verwenden PLM!
ist bestimmt so toll wie alles andere von SAP auch
-
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...
-
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.)
-
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!
-
Wer benutzt denn Subversion noch mit Berkeley-DB? Seit knapp 4 Jahren wird doch fsfs unterstützt.
-
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
-
tfa schrieb:
Wer benutzt denn Subversion noch mit Berkeley-DB? Seit knapp 4 Jahren wird doch fsfs unterstützt.
WIR
-
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.
-
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.
-
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.
-
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? 
-
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.
-
Eine Woche Backup hilft da auch nichts mehr
Ein anständiger Admin backupt jeden Tag.
-
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
-
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.
-
.filmor schrieb:
Für Mercurial gibt's TortoiseHG, [...]Hab ich aber [...] nicht ausprobiert
Zumindest unter Windows performancetechnisch eine Zumutung.
