Subversion 1.0

[SeeksTheMoon]

Tretet CVS in die Tonne! Benutzt SVN 1.0! :D

SVN ist ein moderner, schöner, schneller, perfekter, besserer Ersatz für die alte, schrottige, hässliche Versionsverwaltung CVS. :D
Die Featureliste?
Ich will mal Slashdot zitieren:


If you're new to Subversion its feature list looks like fixes for everything that is wrong in CVS, renaming, directory structure and metadata version tracking, file deletion, proper management of binary files and it's pretty portable to boot.

http://subversion.tigris.org

In der Tutorialsektion hier gibts auch ein Tut von mir.

SVN rult!

[peschmae]

Hmm, das muss wohl mal drauf.

Aber wegen nem kleinen RCS schnell mal nen Apache installieren. :ugly:
Naja, scheint mir bliebe nix anderes übrig.

MfG Peschmä

[SeeksTheMoon]

Du brauchst den Apache gar nicht. Du kannst ihn als Server benutzen, aber Du kannst auch genausogut den xinetd oder den SVN-Server benutzen.
Und Clientseitig brauchst Du ihn sowieso nicht.
Für das Kompilieren braucht man nur eine Lib vom Apachen (APR).

[RapidMax]

Das kommt gerade recht, da ich den Server, auf dem bisher CVS läuft neu aufsetzen will. Dann versuche ich mich gleich mal mit SubVersion.

Bin mal gespannt, wann SourceForge nach SubVersion migrieren wird.

Gruss, Andy

[peschmae]

Original geschrieben von SeeksTheMoon
Du brauchst den Apache gar nicht. Du kannst ihn als Server benutzen, aber Du kannst auch genausogut den xinetd oder den SVN-Server benutzen.
Und Clientseitig brauchst Du ihn sowieso nicht.
Für das Kompilieren braucht man nur eine Lib vom Apachen (APR).

Habs gerade festgestellt. Dann mal los!

Urgh, das Teil mit allen Libs von denen es abhängt benötigt gerade mal 16MB, naja. Es muss wohl sein :)

MfG Peschmä

[dragon's might]

Hmm, wieso ist das nicht unter der GPL?
*zucvsrenn*

[peschmae]

Ist trotzdem frei, sonst wärs nicht in Debian :)

Ausserdem - schau dir mal die Lizenz an.

MfG Peschmä

[randy]

Original geschrieben von dragon's might
Hmm, wieso ist das nicht unter der GPL?
*zucvsrenn*

ich schätz mal gnu arch ist unter der gpl.

was haltet ihr eigentlich von arch? es ist ja auch ein cvs replacement ?
wieso sollte ich gerade subversion verwenden? (ich weis es zwingt mich keiner, blablabla)

mfg
randy²

[THEReapMan]

Original geschrieben von RapidMax
Bin mal gespannt, wann SourceForge nach SubVersion migrieren wird.

So schnell wird das nicht passieren. Wenn du ein Projekt auf sf.net laufen hast wirst du wissen das die entwickeler-cvs-server erst umgezogen sind, und da gabs mächtig probleme. Developer-CVS war gut 3 Wochen down oder kaum erreichbar.
Ich denke das werden die den Entwicklern nicht gleich wieder antun. *hoff*

[SeeksTheMoon]

die Typen von SF.net werden wohl nie umsteigen, denn das Python Script zum Portieren wird bei SF wohl mehrere Tage lang laufen, denn das Script muss die updates von CVS separat auschecken und dann in SVN einchecken (wegen den atomic commits).

Zur Lizenz:
Die Lizenz von SVN ist doch prima, die ist fast 100%ig wie die Apache Lizenz:
Man muss das Copyright und die Lizenz dabei lassen.
Man muss eigene Derivate von SVN entsprechend kenntlich machen
Und die Erweiterung der Apache-Lizenz ist Punkt 4. Der ist auch unkritisch.
Freier ist nur noch Public Domain und die GPL ist ein Gefängnis dagegen. das Teil ist fast so Free wir das Free in BSD ;-)

Warum man gerade SVN benutzen sollte? Weil es das beste freie System ist!
Es gibt sehr, sehr viele Versionsverwaltungssysteme und die freien sind oft ziemlich alt oder bestehen aus 10 verschiedenen+inkompatiblen Weiterentwicklungen von irgendeinem System, sie haben weniger Features, sind nicht plattformunabhängig, oder versuchen dem alten CVS-Käse weitere Features anzukleben.
Die Kommerziellen sind auch nicht alle gut, aber die die es sind, die sind entweder sauteuer, erlauben einem nur freie Software zu entwickeln oder sind völlig proprietär.
Im übrigen ist SVN auch ziemlich Befehls-kompatibel zu CVS und es wird überall als DER CVS-Nachfolger bezeichnet; alles andere kommt nur mit "unter ferner liefen" davon.

Ich habe mich wegen einem Softwareprojekt intensiv mit diesen Systemen befassen müssen. Für mich speziell gibt es keine bessere Wahl und das dürfte auf 90% der übrigen Anwender auch zutreffen.

Hier noch ein paar Macken anderer Systeme die mir einfallen:
Arch erlaubt keine Leerzeichen in Dateinamen
Aegis hat Probleme mit Versionsnummern, Kopien und Rechten
RCS ist ja noch älter als CVS
Meta-CVS kleistert auf CVS nur drauf
und die 50 anderen benutzt/kennt keiner.

Im Netz hatte ich mal ne Seite gefunden, auf der extrem viele Systeme aufgelistet waren, aber den Link hab ich nicht mehr.

[chrizel]

Ich hab gestern auch Subversion getestet... hab mich etwas eingelesen im sehr guten Handbuch (http://svnbook.red-bean.com/). Auch für Versionskontroll-Anfänger geeignet...

Ich muss sagen dass ich bisher nicht so viel mit CVS gemacht habe (aber ich hab bei sf.net sogar ein Projekt, läuft aber derzeit nicht aktiv). CVS hat mich irgendwie immer abgeschreckt. Ich hatte auch schon damit zu kämpfen als ich Verzeichnisse löschen wollte.

Und selbst für mich - als CVS-Newbie - Subversion macht einen besseren Eindruck - macht sogar irgendwie Spass... dass das ganze über apache laufen kann ist doch wunderbar.

Das ganze ist einfach. Durchschaubar. Gut dokumentiert. Logisch. Und besser als CVS. :D

[iGEL]

Moin!

Ich habe mir weite Teile der Doku durchgelesen, und was ich da gesehen habe, gefällt mir schon mal sehr gut. Wenn die jetzt noch einen besseren Support fürs Mergen (siehe hier (http://svnbook.red-bean.com/html-chunk/ch04s03.html#svn-ch-4-sect-3.2)) hinbekommen, ist es wirklich gut. Weiss jemand, ob das ein für die nächste Zeit geplantes Feature ist?

Meine eigentliche Frage ist aber: Ich verstehe nicht ganz, wie SVN entscheidet, was ein Projekt ist und was mehrere sind. Bei CVS spielt das ja keine Rolle, da es eh nur einzelne Dateien versioniert, aber SVN wird ja der ganze Verzeichnisbaum eines Projekts gleich versioniert. In einem Repository können ja aber nun mehere Projekte liegen. Bis eben dachte ich, das, was in einem Import in das Repository hinzugefügt wird, wird als ein Projekt angesehen, aber dann bin ich auf diese Stelle (http://svnbook.red-bean.com/html-chunk/ch05s04.html#svn-ch-5-sect-6.2) im Manual gestoßen, wo gleichzeitig 2 Projekte samt "trunk, branch, tag"-Verzeichnisstruktur importiert werden. Würde dann nicht jede Aktion im einen Projekt die Revision im anderen erhöhen?

Übrigens, hier wurden 10 Version Control Systeme verglichen: http://better-scm.berlios.de/comparison/

Zu Sourceforge: Ich könnte mir vorstellen, dass die Subversion zusätzlich anbieten und es den Leuten überlassen, das Projekt zu transferieren.

iGEL

[SeeksTheMoon]

Wenn die jetzt noch einen besseren Support fürs Mergen (siehe hier (http://svnbook.red-bean.com/html-chunk/ch04s03.html#svn-ch-4-sect-3.2)) hinbekommen, ist es wirklich gut. Weiss jemand, ob das ein für die nächste Zeit geplantes Feature ist?

Steht auf der Startseite:
"Features planned for after 1.0

Support for symbolic links ...

Better merge support:
Improved support for selective merges from related lines of development, and for repeated merges. (Currently, Subversion's merge support is essentially the same as CVS's.)

Broader WebDAV compatibility ...
Support for plug-in client side diff programs ...
Internationalization ...
Progressive multi-lingual support ...


Ich verstehe nicht ganz, wie SVN entscheidet, was ein Projekt ist und was mehrere sind.
Das weiß ich jetzt auch noch nicht; ich hab einfach 3 verschiedene Repositories für meine 3 Projekte angelegt; muss ja nicht alles in der gleichen Datenbank sein.
So hab ich das auch bei CVS früher gemacht.

[iGEL]

Moin!
Original geschrieben von SeeksTheMoon
Steht auf der StartseiteOk, danke! *peinlich* ;)
ich hab einfach 3 verschiedene Repositories für meine 3 Projekte angelegt; muss ja nicht alles in der gleichen Datenbank sein.
So hab ich das auch bei CVS früher gemacht.Versuch macht kluch: Das scheint auch der beste Weg zu sein. Die Revisionen werden offenbar Repositoryweit vergeben, daher, jede Änderung erhöht die Revision jeder Datei im selben Repository.

iGEL

[chrizel]

Original geschrieben von iGEL

Meine eigentliche Frage ist aber: Ich verstehe nicht ganz, wie SVN entscheidet, was ein Projekt ist und was mehrere sind.

Tut es auch nicht. Wie du schon gesagt hast werden Revisions-Nummern Repository-Weit vergeben. Wenn du ein Projekt hast z.B. mit aktueller Revision 310, und du nun ein neues Projekt importierst fängt das neue Projekt bei Revision 310 (bzw. 311...) an, und nicht bei 0.

[SeeksTheMoon]

stimmt; das ist auch ein Vorteil gegenüber CVS. Dort musste man Tags setzen oder sich ein Datum mit Uhrzeit merken, wenn man eine bestimmte Version gemeint hat.
Bei SVN kann man sich nur die Revision merken wenn man auf einen bestimmten Stand zugreifen will. Das ist auch eindeutiger als ein Datum:
Bei CVS fragt man seinen Mitarbeiter "Von wann ist denn Deine Version?" "Von heute" "Wieviel Uhr? 8:15 oder 8:20?" "Öhm..ich such mal schnell von allen Dateien ihre Versionsnummern zusammen". Und wenn sie nicht gestorben sind, dann suchen und taggen sie sich noch heute einen zusammen. *g*
Bei SVN kann er hingegen direkt sagen, "ich hab Revision 290".

[randy]

@ all

ein bericht über subversion ist bei oreilly erschienen.
http://osdir.com/Article203.phtml

-----

@seeks the moon:
y-windows verwendet ja ARCH als version control system. ist das bei diesem projekt gescheiter arch einzusetzen? wäre es mit subversion besser?

mfg
randy²

[SeeksTheMoon]

Die Entwickler haben sicher einen Grund dafür, warum sie sich für Arch entschieden haben.

[SeeksTheMoon]

subversion 1.0.1 ist raus. Es ist ein Bugfix release.