Das deutsche Python-Forum

Leonidas hat geschrieben:Wenn es GUI sein muss [...]

Ich finde, muss es nicht. Ich hab schneller "svn ci -m blah" eingetippt, bevor RapidSVN überhaupt gestartet ist, aber zur um den Überblick zu behalten ist es nicht schlecht.

Mal ne Frage, die ich schon immer mal an die Allgemeinheit richten wollte: Wie haltet ihr das mit den Repos und euren Projekten? Legt ihr für jedes Projekt ein neues Repo an? Mach ich nämlich nicht, obwohl es sicher manchmal praktisch wäre, wenn man sich mit einem Projekt mal total verrannt hat. Dann kann man es später noch restlos entfehrnen, was nicht geht, wenn alles in einem Repo liegt...

ProgChild hat geschrieben:Legt ihr für jedes Projekt ein neues Repo an? Mach ich nämlich nicht, obwohl es sicher manchmal praktisch wäre, wenn man sich mit einem Projekt mal total verrannt hat. Dann kann man es später noch restlos entfehrnen, was nicht geht, wenn alles in einem Repo liegt...

Hi ProgChild!

Man kann mit Subversion aus einem alten Repository ein neues erstellen und bei diesem Vorgang einen Filter definieren, der z.B. einen bestimmten Zweig nicht ins neue Repository übernimmt, oder nur einen bestimmten Projektzweig ins neue Repository übernimmt.

Das ist mir aber alles zu umständlich. Ich habe für jedes Projekt ein eigenes Repository. So lange dauert das bei mir auch wieder nicht, ein neues Repository anzulegen.

Code: Alles auswählen

1. 
/etc/init.d/apache2 stop
su apache
svnadmin create /svn/dev/repositoryname
2.
Mit dem Midnight Commander kopiere ich die Einstellungen,
Berechtigungen und Hooks aus einem anderen Repository
in das neue Repository.
exit
3.
Im Apache einen neuen Webdav-Eintrag schreiben (copy, paste)
/etc/init.d/apache2 start
4. 
In der Konfigurationsdatei des *WebSVN* eine neue
Zeile für das neue Repository hinzufügen.
Fertig.

Wenn ich langsam bin, brauche ich dafür drei Minuten unter Gentoo-Linux.

lg
Gerold

Bei mir liegt ein Projekt in einem eigenen Repository, die Restlichen liegen im "snippets" Repostiory. Dort liegen auch andere Projekte, die eigentlich nicht mehr Snippets sind, also müsste ich sie vielleicht mal wo anders hinschieben. Aber bis jetzt geht das auch so wie es ist.

ProgChild hat geschrieben:
Leonidas hat geschrieben:Wenn es GUI sein muss [...]
Ich finde, muss es nicht. Ich hab schneller "svn ci -m blah" eingetippt, bevor RapidSVN überhaupt gestartet ist.

*zustimm*, ich verwende generell nur die kommandozeile für die reop Sachen, für den Überblick habe ich Trac.

ProgChild hat geschrieben:Mal ne Frage, die ich schon immer mal an die Allgemeinheit richten wollte: Wie haltet ihr das mit den Repos und euren Projekten? Legt ihr für jedes Projekt ein neues Repo an? Mach ich nämlich nicht, obwohl es sicher manchmal praktisch wäre, wenn man sich mit einem Projekt mal total verrannt hat. Dann kann man es später noch restlos entfehrnen, was nicht geht, wenn alles in einem Repo liegt...

Jedes Projekt bekommt bei mir in der Regel ein eigenes Repo inkl dazugehörigen Trac.

Hallo?
darcs wenn man viel Zeit hat?
Dann hast entweder du darcs nicht verstanden oder ich habs total gefressen denn das einspielen eines patches geht genau so schnell und leicht wie das uploaden bein svn, cvs oder sonstwas. git kenne ich zugegebenermaßen nicht.
Auf darcs bin ich btw. durch uuu gekommen, die verwenden das auch (nur mal so als "Referenz")

Was kann git denn mehr/besser als darcs?

Warum soll svn besser geeignet sein? Ich konnte mit darcs bis jetzt alles machen, was ich wollte/brauchte... Zugegeben meine cvs/svn-Zeit ist ein bisschen her, aber ich hab das Gefühl, dass es mit darcs schöner geht.

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

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

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

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

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.

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.

henning hat geschrieben: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

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?

henning hat geschrieben: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

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)

henning hat geschrieben:(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.

henning hat geschrieben: - 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.

BlackJack hat geschrieben: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.

Das deutsche Python-Forum

Versionsverwaltungen