Versionsverwaltungen

[henning]

Okay, hab jetzt noch ein bisschen gegooglet und gelesen, dass man angeblich mit darcs nicht zu jedem früheren Zeitpunkt zurückgehen kann, was natürlich nicht so schön ist.

Trotzdem bleiben noch 2 Fragen:
- Was soll der grunsätzliche unterschied der Ansätze von darcs/git und cvs/svn sein?

- Was "soll" man denn jetzt nehmen? Ist svn echt noch das Beste? Sind Bazaar oder Codeville vielleicht schon besser?

Danke für eure Geduld

[mitsuhiko]

@henning:
Du kannst darcs/git und svn/cvs nicht vergleichen.

DARCS/git haben verteilten Absatz, cvs/svn nicht.

[henning]

Naja, aber zumindest darcs kann man ja -wenn man will- genau so zentralisiert nutzen wie z.B. svn, indem man halt ein repository als "server" verwendet.
Gemnau so benutze ich es auch zur Zeit, wie gesagt, bislang auch ohne Probleme...

[Leonidas]

SVN kann man über SVK auch verteilt nutzen.

Ich finde SVN halt intuitiver: das Repository hat eine Revision, ich kann vor und zurückgehen, branchen und mergen via Kopie usw.

Das ist warscheinlcih auch geschmackssache, das besste SCM gibt es nicht: es gibt nur das bessere SCM für einen bestimmten Einsatzzweck. Ob das nun SVN, SVK, Darcs, Monotone, Bazaar-NG, Codeville, git oder was anderes ist.

[henning]

Also, okay, da ich wie gesagt jetzt mal irgendwo gelesen habe, dass man mit darcs wohl nicht immer an jeden Früheren Zeitpunkt zurück kann, werde ich wohl umsteigen. Vielleicht könnt ihr mir ja einen Rat geben, also ich hätte gerne folgendes (Nach Wichtigkeit abteigend geordnet:

- Ich möchte jeden früheren Zeitpunkt wiederherstellen können, falls mal irgendwas schief gegangen ist.
edit:
- SSH-Zugriff muss auf jeden Fall möglich sein, ich möchte dafür nicht am Webserver rumbasteln müssen. (Hat verschiedene Sicherheitsgründe)
/edit
- Ich möchte die Möglichkeit haben, z.B. an einem update länger zu arbeiten bevor ich es hochlade, zwischendurch aber z.B. bugfixes hochzuschieben.
Wenn ich dann mit der längeren Sache fertig bin, sollen die Bugfixes natürlich nicht weg sein. (Müsste man IMHO mit ziemlich jedem System hinkriegen, oder?)
- Ich möchte ab und zu "Releases" machen, spätestens dann brauche ich eine Versionsnummer, die kann (muss aber nicht) auch schon vorher mitlaufen. Da ich für die Releases eh ein script schreiben will, (weil da noch ein bisschen was anderes getan werden muss) könnte ich das aber auch selbst mit rein basteln.
- Ich hab mir subversion mal angeguckt (und mir ist aufgefallen, dass ich damit noch nicht gearbeitet hatte, da muss früher wohl echt cvs gewesen sein) und muss sagen, dass mir diese Datenbank-kramerei ein bisschen missfällt im repository. Spart zwar ordentlich Platz, ist nach meinem Geschmack zu Black-Box-mäßig. Da kann ich mich aber eohl schnell dran gewöhnen, zumal man backups ja mit nem checkout machen kann.

Was wäre unter diesen Aspekten am Besten geeignet? Vielleicht Subversion oder Bazaar-NG?

Nachtrag:
Ganz gut wäre auch, wenn ich dir Möglichkeit hätte, "patches" via Email einzuspielen, da ich nicht weiß, ob der ssh-Zugriff so bequem bleiben wird.

[gerold]

Vielleicht könnt ihr mir ja einen Rat geben,

Hi Henning!

Patches kannst du nicht via Email ins Subversion-Repository einspielen. Vielleicht gibt es da ein Tool dafür, das weiß ich nicht.

Aber ansonsten ist Subversion genau das Versionsmanagement-System das ich immer gesucht habe. Ich kann es *uneingeschränkt* weiterempfehlen. Egal, ob du Subversion mit einem grafischen Tool oder über die Kommandozeile bedienst.

Erstens empfehle ich hier Subversion und zweitens das Buch "Subversion" von Frank Budszuhn. (ISBN 3-89842-603-3). Es führt dich in den Entwicklungsprozess mit Subversion ein und erklärt die Arbeit mit Subversion bis ins letzte Detail. Vom Verwalten bis zum Zusammenführen einzelner Dateien.

lg
Gerold

[henning]

Mir ist grad selbst noch ein Gegenargument für subversion wingefallen (deine Empfehlung in allen Ehren):

Es geht nämlich um ein Web-Datenbank Projekt, und wir wollen dabei zwei Versionen parallel laufen lassen: Die letzte Release und die frisch gepachte VCS-Version.
Mit darcs war das immer kein Problem, da hat apache einfach auf das zentrale repository verwiesen, und alle waren glücklich ,-)
Mit svn müsste ich ja immer wieder einen extra checkout für apache machen, oder?
Und svk da nochmal draufzupflanzen... würde es da nicht mehr Sinn machen gleich ein dezentrales Ding zu nehmen zumal ich ja eh noch ne Erweiterung raufflanschen müsste für mein Email-Kram? (Falls es eines gibt, dass meine Anforderungen erfüllt)


PS:
Kannst du als svn-Fan mir evtl. sagen, warum die URLs für ssh-Verbindungen diese komische Form haben (svn+ssh://server/path/to/repo)?
Wäre nicht ssh://server/path/to/repo oder server:/path/to/repo logischer?

[gerold]

Mit darcs war das immer kein Problem, da hat apache einfach auf das zentrale repository verwiesen, und alle waren glücklich ,-)
Mit svn müsste ich ja immer wieder einen extra checkout für apache machen, oder?
[...]
PS:
Kannst du als svn-Fan mir evtl. sagen, warum die URLs für ssh-Verbindungen diese komische Form haben (svn+ssh://server/path/to/repo)?
Wäre nicht ssh://server/path/to/repo oder server:/path/to/repo logischer?

Hi Henning!

So schlimm ist das auch wieder nicht.
Du kannst Skripte bei verschiedenen Events ausführen lassen. Z.B. könntest du das Skript

Code: Alles auswählen

svn export /home/svn/meinrepository/trunk /home/xxx/zielordner

automatsich beim Event "commit" ausführen lassen. So wird, jedes mal, wenn jemand einen "commit" durchführt, der aktuelle Entwicklungszweig in einen dafür vorgesehenen Ordner exportiert.

Das mit "svn+ssh" kann ich dir nicht erklären, aber es stört mich ja auch nicht, da ich immer über Webdav (http oder https) auf meine Repositories zugreife. Über den Apachen kann ich da exakt definieren, wer, mit welchen Rechten auf welchen Repositoryzweig zugreifen darf.
Das hat Vorteile, wenn du auf dein Repository über das Internet zugreifen möchtest. SSH hat den Nachteil, dass alle, die auf das Repository per SSH zugreifen möchten, das Recht dazu haben müssen. Es kann also sein, dass dir jemand die Zugriffsrechte auf eine Datei im Repository verhaut. Das kann man mit einem Skript wieder hinbiegen, aber es ist nicht schön.

lg
Gerold

[henning]

Das kommt natürlich auf die Projekte bzw. Leute an.
Also ich hab z.B. die Situation, dass wir nur zu zweit an einem Projekt arbeiten, und das Projekt auch nicht weiter aufgeteilt ist.

Ausserdem richte ich lieber nen neuen user-account ein und setzte verzeichnis-Zugriffsrechte, als dass ich meine Apache-Konfiguration noch komlizierter mache (zumal HTTP ja eigentlich einen leicht anderen Zweck hat, als Daten für VCSs zu übertragen)

[Leonidas]

(zumal HTTP ja eigentlich einen leicht anderen Zweck hat, als Daten für VCSs zu übertragen)

HTTP vielleicht schon, aber die HTTP Erweiterungen WebDAV (und DeltaV) welche Subversion nutzt sind genau das richtige dafür. Allerdings ist die Konfiguration zugegebenermaßen nicht ganz so trivial.

Ich habe mein Projekt so organisiert: HEAD (sozusagen) und Release.

Wenn du was verteiltes willst, kannst du Arch/Bazaar(-NG) ansehen, von Arch haben viele geschwärmt, aber es ist nun tot und ich bedauere es nicht. Vielleicht macht Bazaar-NG es nun besser.

Schön bei Subversion ist die umfangreiche Doku, wo SVK auch schon nachzieht.

Den E-Mail Kram könntest du vermutlich mit einem selbstgeschreibenen Tool machen, da Subversion Python-Bindings ja gereitstellt. Aber vielleicht gibt es das ja auch schon.

[BlackJack]

- Ich möchte die Möglichkeit haben, z.B. an einem update länger zu arbeiten bevor ich es hochlade, zwischendurch aber z.B. bugfixes hochzuschieben.
Wenn ich dann mit der längeren Sache fertig bin, sollen die Bugfixes natürlich nicht weg sein. (Müsste man IMHO mit ziemlich jedem System hinkriegen, oder?)

Dazu macht man ja ab und zu updates bei den Quellen mit denen man, in diesem Fall längere Zeit, arbeitet.

- Ich möchte ab und zu "Releases" machen, spätestens dann brauche ich eine Versionsnummer, die kann (muss aber nicht) auch schon vorher mitlaufen.

Branches und Tags werden bei SVN einfach durch Kopien innerhalb des Repository gelöst. Man kopiert bei einem Release also im Repository vom "HEAD" z.B. `../projektname/trunk/` nach `../projektname/releases/version_x.y.z/`. Dort hat man dann den "eingefrorenen" Zustand zum aktuellen Zeitpunkt.

Wenn man mit mehreren Leuten an einem Projekt arbeitet kann es natürlich vorkommen, das zwischen dem Zeitpunkt wo Du meinst der aktuelle Stand sollte ein Release werden und dem Kopieren, ein anderer Entwickler noch etwas eincheckt. Deshalb sollte man die Revisionsnummer des "Releasezustandes" für das Kopieren angeben.

An diesem Punkt finde ich die globale Revisionsnummer von SVN gegenüber CVS sehr praktisch weil jede Rev-Nummer quasi einen Schnappschuss/Gesamtzustand des Repository kennzeichnet.

- Ich hab mir subversion mal angeguckt (und mir ist aufgefallen, dass ich damit noch nicht gearbeitet hatte, da muss früher wohl echt cvs gewesen sein) und muss sagen, dass mir diese Datenbank-kramerei ein bisschen missfällt im repository. Spart zwar ordentlich Platz, ist nach meinem Geschmack zu Black-Box-mäßig.

Das sollte ein Versionsverwaltung doch eigentlich auch sein!? "Hinter" der API die nach aussen angeboten wird, sollte niemand an den Daten herumpfuschen können.

Datenbank muss übrigens nicht sein, es gibt auch ein alternatives Backend das glaube ich `filefs` oder so heisst.

Da kann ich mich aber eohl schnell dran gewöhnen, zumal man backups ja mit nem checkout machen kann.

Backups mache ich immer per ``svnadmin dump``. Damit bekommt man den gesamten Repositoryinhalt, also inklusiver der "Historie" als Textformat das unabhängig vom Backend ist.

Noch zur Frage warum `svn+ssh://`: Es gibt auch `svn://`, das ist das SVN eigene Protokoll ohne SSH.

[Leonidas]

Datenbank muss übrigens nicht sein, es gibt auch ein alternatives Backend das glaube ich `filefs` oder so heisst.

Es heißt FSFS und ist soweit ich mich erinnern kann, in Subversion 1.1 dazugekommen, neben dem BSDDB-Backend, welches es schon seit immer gab.

Ich muss sagen, das arbeiten mit Subversion ist durchaus angenehm, es hat ein paar Vorteile gegenüber CVS, ohne komplett neue Wege zu gehen, sondern es hat aus den Fehlern von CVS gelernt.