CVS oder SVN?

nman

Tachyon schrieb:

Siassei schrieb:

[...]Begründung: Beide System laufen lokal auf deinem Rechner und somit funktionieren beide auch dann[...]

Und das trifft auf CVS und SVN nicht zu

Insofern nicht, als CVS und SVN beide einen Server benötigen, den Du irgendwo installieren musst, zB. bei Dir zuhause.

Verteilte Versionskontrollsysteme brauchen hingegen keinen Server. Du kannst zwar einen verwenden, aber Du kannst auch komplett ohne arbeiten.

curry-king: CVS ist von vorvorgestern und SVN von vorgestern. Nimm Git, da brauchst Du nur lokal überall Git installieren. Wenn Du Deine Sourcen dann irgendwo auf einem zentralen Server haben möchtest, installierst Du dort auch Git und machst hin und wieder "git push" und die Sache ist gegessen.

http://git-scm.com/
http://whygitisbetterthanx.com/

Und falls Du Windows verwendest und tortoisesvn magst, gibts natürlich auch GUI-Tools wie tortoisegit

rüdiger

Weder CVS noch SVN. CVS ist ja sogar noch schmerzhafter als SVN. Subversion ist wirklich langsam, man benötigt ständig den Server, branchen/merging ist eine frickelige Angelegenheit, etc.

Das man ständig einen Server braucht ist ja gerade für private Projekte nervig. Machst du regelmäßig ein Backup von dem Server? Bei einem verteilten VCS wie git oder mercurial ist jedes Repo vollwertig und man verliert nicht die ganze Geschichte, wenn mal der Server stirbt.

CVS und SVN sind einfach von gestern bzw. vorgestern. Heutzutage nutzt man git oder mercurial.

Was redet ihr denn da? Bei Subversion brauche ich nicht unbedingt einen Server. Ich kann ein Subversion Repository einfach in einem Verzeichnis anlegen und gut ist.

Sicher ist Git oder Mercurial moderner und besser, aber so schlecht ist Subversion ja auch nicht.

Kann mich meinem Vorgänger nur anschließen...

ich nutze SVN+Turtoise+Ankh und man benötigt dafür DEFINITIV keinen Server. Ich habe mein privates Repository z.B. auf einem Stick liegen (zum lässigen Wechseln zwischen PC, Notebook und Arbeit).

Ach, nicht aufregen. Wenns um git geht, kommt bei diversen leuten gern mal der fanatismus raus. Nix neues.

Benutzte auch SVN. Ohne "server".

nman

SolidOffline schrieb:

Ich habe mein privates Repository z.B. auf einem Stick liegen (zum lässigen Wechseln zwischen PC, Notebook und Arbeit).

Den brauchst Du auch, wenn Du keinen Server betreiben möchtest und trotzdem von mehreren Rechnern aus bequem SVN verwenden möchtest. Und wenn der Stick kaputtgeht, ist die gesamte Versionsgeschichte weg, sofern Du sie nicht irgendwohin synchronisiert hast.

Bei verteilten Versionskontrollsystem ist genau dieses synchronisieren integraler Bestandteil des VCS und braucht nicht so krampfige Tools wie svnsync, mit denen in der Regel alles außer trivialer Repo-Replikationen ein Kampf ist. (Merging in Subversion ist einfach nur schmerzhaft, auch ganz ohne replizierte Repos.)

(Und wenn ein zentrales Repo (sofern vorhanden) kaputtgeht, ist immer noch jeder Checkout ein vollwertiger Klon.)

Ob Du nun Mercurial oder git nimmst, ist dabei weitestgehend Geschmackssache, aber wenn Du mit Versionskontrolle gerade frisch anfängst, dann tu Dir den Gefallen und fange nicht mit veralteten Tools an, die die meisten Leute nur mehr aus Gewohnheit und Angst vorm Umsteigen benutzen. (Solltest Du irgendwann mal in die Verlegenheit kommen, SVN verwenden zu müssen, kannst Du als Client übrigens einfach Mercurial oder git verwenden und lokal vernünftig offline arbeiten.)

nman

edit: wakckelige Verbindung, Doppelpost

Siassei

KuhTee schrieb:

Ach, nicht aufregen. Wenns um git geht, kommt bei diversen leuten gern mal der fanatismus raus. Nix neues.

Benutzte auch SVN. Ohne "server".

Das wird wohl ein Flameware
Subversion hat eine sehr guten Ruf und wird seit Jahren benutzt. Für das arbeiten mit den Daten wird keine Verbindung zum zentralen Repository benötigt.

Erst bei Änderungsanfragen (merge, commit, ...) muss eine Verbindung zum zentralen Repository bestehen. Zudem geht man das Risiko ein, dass beim einem Crash des zentralen Repository die gesamte History verloren geht.

Dezentrale Systeme haben diesen Nachteil nicht. Dort stellt jede Kopie ein vollwertiges Repository dar.
Da sollte man den Wiki-Artikel durchlesen: http://de.wikipedia.org/wiki/Versionsverwaltung#Verteilte_Versionsverwaltung

SolidOffline schreib:

ich nutze SVN+Turtoise+Ankh und man benötigt dafür DEFINITIV keinen Server. Ich habe mein privates Repository z.B. auf einem Stick liegen (zum lässigen Wechseln zwischen PC, Notebook und Arbeit).

Das zentrale Repository liegt sommit auf dem USB-Stick. Mit der installierten Software betreibst du einen "Server" (biete nicht 1zu1 verstehen) auf jeden Computer. Aber das ist nicht genau das, was wir hier meinen.
Wenn du das so machst, dann ist das schön und gut. Aber du wirst hier nicht abstreiten, dass du ein zentrales Repository besitzt und auf diesem alle Änderungen durchgeführt werden.
Somit arbeitest du nicht mit einer lokalen Kopie, sondern direkt auf dem zentralen Repository und schlepst dieses von Ort zu Ort. In diesem Fall unterscheiden sich zentrale und verteilte Systemen nicht.

Gruß,
Thomas

nman

Siassei schrieb:

Erst bei Änderungsanfragen (merge, commit, ...) muss eine Verbindung zum zentralen Repository bestehen.

Und für alles, was irgendwie mit Versionsgeschichte zu tun hat. Somit braucht man also für "svn log", Blame und Bisect Serververbindungen. Und die entsprechenden Anfragen sind dann auch quälend langsam.

EXDW

Kann ich nur empfehlen: http://chaosradio.ccc.de/cre130.html

Blue-Tiger

Hab frueher auch SVN verwendet und bin jetzt bei git. Der Umstieg brachte keine Nachteile, keine Vorteile mit sich. Wenn du "frisch" anfaengst, gibts echt absolut keinen Grund, bei sowas Altem wie SVN zu bleiben.

RHBaum

Es gibt mit Sicherheit auch Szenarien, die eher fuer svn sprechen.

Und für alles, was irgendwie mit Versionsgeschichte zu tun hat. Somit braucht man also für "svn log", Blame und Bisect Serververbindungen. Und die entsprechenden Anfragen sind dann auch quälend langsam.

Muss ich bedingt zustimmen, aber wir haben bisher noch keine andere alternative wirklich ausmachen koennen.

Unsere Anforderungen z.b.:
- Defizieles RechteManagment
- Kommunikation ueber nur bestimmte protokolle fuer externe zugriffe. FTP/SFTP faellt raus wegen Sicherheitsapekte, direktzugriff (SSH, telnet ... ) faellt raus wegen Sicherheitsaspekte ... nfs/cifs(smb) no chance ... das einzige was geht ist http/https
- zentrales Managment vs. dezentrales. Wenn man die Projecte und zustaendigkeiten klar abgrenzen kann, iss nen dezentrales sicher besser. Hat man viele Anteile, wo fuer eine Datei z.b. viele Maintainer zustaendig sind, laeufst eh schnell in Probleme. Da iss nen klassisches zentrales System mit onlinezwang eher positiv.
Wenn ich bei einem so einen Project mal 3 Tage ned Comitte, bin ich hinterher locker schneller wenn ich meine Aenderungen verwerfe und in den aktuellen Stand komplett neu einpflege, als wie wenn ich die Kollisionen bearbeite ....
Klar, das Projectmanagment an der STelle iss ned so optimal, geht aber manchmal ned anders ...

Ciao ...

nman schrieb:

SolidOffline schrieb:

Ich habe mein privates Repository z.B. auf einem Stick liegen (zum lässigen Wechseln zwischen PC, Notebook und Arbeit).

Den brauchst Du auch, wenn Du keinen Server betreiben möchtest und trotzdem von mehreren Rechnern aus bequem SVN verwenden möchtest. Und wenn der Stick kaputtgeht, ist die gesamte Versionsgeschichte weg, sofern Du sie nicht irgendwohin synchronisiert hast.

Und wenn ich ausschliesslich auf einem Rechner arbeite und git verwende und dann meine Festplatte abraucht, dann ist bei git die Versionsgesschichte etwa nicht weg? Ein Versionsverwaltungssystem ist kein Ersatz für ein Backup.

Man kann mit svn sehr viel machen. Dass mit git mehr geht, ist sicher so, aber wenn svn reicht, dann reicht svn.

Vielleicht könnte man sich darauf einigen, dass folgende Aussagen in Bezug auf SVN falsch sind:

- git und mercurial sind besser weil: Beide System laufen lokal auf deinem Rechner und somit funktionieren beide auch dann, wenn du mal keine Internetverbindung hast. Wenn eine Verbindung besteht, kannst du die Änderungen mit dem Server abgleichen.

Aussage falsch, weil: SVN ebenfalls lokal läuft und ebenfalls auch dann bestens funktioniert, wenn keine Internetverbindung besteht.

- ... CVS und SVN beide einen Server benötigen, den Du irgendwo installieren musst, zB. bei Dir zuhause.

Aussage falsch, weil: SVN keinen Server benötigt, den man irgendwo installieren muss.

Alles unter der Annahme, dass ein Server nicht mit einem Verzeichnis gleichzusetzen ist.

Vielleicht könnte man sich dann darauf einigen, dass folgende Aussage wahr und unmissverständlich ist:

- Für SVN wird ein zentrales Repository benötigt (sofern man auch mal commiten möchte ), was dann einen Unterschied zu z.B. git oder mercurial darstellt, sobald man auf mehr als einem Rechner arbeiten möchte.

Zur "privaten Nutzung" kann ich SVN also auch ohne Internetverbindung und Server empfehlen.

Das Repository sollte (wie eigentlich alle Daten) natürlich regelmäßig gesichert werden.

EXDW

ich bins schrieb:

nman schrieb:

SolidOffline schrieb:

Ich habe mein privates Repository z.B. auf einem Stick liegen (zum lässigen Wechseln zwischen PC, Notebook und Arbeit).

Den brauchst Du auch, wenn Du keinen Server betreiben möchtest und trotzdem von mehreren Rechnern aus bequem SVN verwenden möchtest. Und wenn der Stick kaputtgeht, ist die gesamte Versionsgeschichte weg, sofern Du sie nicht irgendwohin synchronisiert hast.

Und wenn ich ausschliesslich auf einem Rechner arbeite und git verwende und dann meine Festplatte abraucht, dann ist bei git die Versionsgesschichte etwa nicht weg? Ein Versionsverwaltungssystem ist kein Ersatz für ein Backup.

Stimmt schon, nur Git hat ein Automatisches "Backup".
Jeder der aus checkt hat es, wenn deine Platte ab raucht, frag jemanden der es noch aus gecheckt hat ob er dir sein Repo geben kann, schon ist alles wieder da.

@SolidOffline
Was ist wenn du Online sowie Offline arbeiten können willst? Dann musst du immer das Repo lokal und auf den Server manuell Synchronisieren, mit History und alles -> Viel Spaß.

Mit "Server" ist ein zentrales Repository gemeint.

Nochmal: die ersten zwei Aussagen bzgl. SVN waren falsch. Nicht mehr und nicht weniger. Und genau darauf habe ich hingewiesen.

Mein zentrales Repository liegt auf einem USB-Stick. Das ist weder ein Server, noch hat das irgendwas mit Internet oder Online und Offline zu tun, noch muss ich das mit einem anderen Repository synchronisieren, weil es IST das zentrale Repository.

Es wird ausschließlich von mir PRIVAT auf mehreren Rechnern genutzt, nie von mehreren Benutzern gleichzeitig.

Deshalb meine gewagte Aussage "SVN kann ich zur privaten Nutzung empfehlen".

Dass andere VCS evtl. besser, schneller, zuverlässiger sind, will ich nicht bestreiten, ist mir auch relativ egal, da SVN für mich zur privaten Nutzung völlig ausreicht und sich auch noch schön mit Ankh im Visual Studio eingliedert, nebenbei bemerkt.

Dravere

Ich war vor kurzem noch bei SVN, habe dann Git ausprobiert und später Mercurial. Alle neuen Projekte fange ich nun mit Mercurial an. Gibt da auch eine wunderbare Integration in Windows: TortoiseHg.

Meine 4 bisherigen wesentlichen Vorteile gegenüber lokales SVN sind die folgenden:
1. SVN ist sogar lokal verdammt schnarch langsam. Hg und Git sind wesentlich schneller.
2. SVN setzt überall einen blöden ".svn" Ordner ab. Bei Hg und Git ist dieser nur im obersten Ordner vorhanden und sonst nirgends.
3. Branching, Merging, usw. sind deutlich einfacher über Hg und Git. Es ist so einfach, dass es etwas ganz natürliches wird. Bei SVN habe ich mich immer wenn möglich darum gedrückt.
4. Die dezentrale Möglichkeit von Git und Hg sind einfach der Hammer. Musste ein paar Wochen weg, wollte die Arbeit mitnehmen. Schnell auf einer USB HD ein Repository erstellt, einen Pull durchgeführt, unterwegs gearbeitet, zurückgekommen, einen Push durchgeführt und ich konnte wieder lokal weiterarbeiten. Das geht äusserst leicht von der Hand. Ich möchte dies unbedingt mal im Team verwenden. Da könnte man zum Beispiel ein zentrales Repository machen und jeder arbeitet zuerst lokal auf seinem Repository. Wenn gewisse Ziele erreicht sind, kann man einen Push auf das zentrale Repository machen. Unglaublich Geschwindigkeit garantiert und man muss nicht gleich alle Branches und co allen anderen bekannt machen, sondern kann wirklich lokal bei sich arbeiten und dann am Ende nur das übertragen, was auch Sinn macht.

Noch kurz was zu Mercurial vs Git:
Ich persönlich verwende Mercurial aus zwei Gründen. Zum einen finde ich die Integration auf Windows irgendwie reifer und besser. Git ist immer noch zu stark auf Linux orientiert und das Windows Team scheint immer noch zu klein zu sein. Mercurial dagegen scheint einen recht guten Windows Support zu haben.
Der zweite Grund, wieso ich mich für Mercurial entschied, ist dessen Einfachheit gegenüber Git. Ich kam in Mercurial wesentlich schneller rein als in Git. Git ist einfach ein Monstrum an Möglichkeiten. Man hat eine grosse Vielfalt und dadurch eben auch viel zum lernen und verstehen. Mercurial scheint mir da einfach etwas schlanker zu sein und reicht für meine Bedürfnisse absolut. Das war/ist aber vor allem ein sehr subjektives Empfinden.

Grüssli

nman

Zu all den "SVN reicht auch"-Posts: Natürlich kann man auch mit schlechten Werkzeugen arbeiten. Ich löte auch immer noch mit einem 10€-Lötkolben und habe ganz brauchbare Resultate. Allerdings würde ich wenn ich ohne finanziellen Aufwand für zuhause eine der hübschen Weller-Stationen, die wir auf der Uni haben, bekommen könnte ohne zu zögern eine nehmen. Meine Elektronikprojekte würden dadurch nicht zwangsläufig besser, aber die Arbeit an sich wäre definitiv angenehmer, wenn ich nicht immer ewig warten müsste, bis das Eisen heiß ist oder mich über die ungleichmäßige Temperaturverteilung und die ständig oxidierende Spitze ärgern müsste.

SolidOffline schrieb:

- git und mercurial sind besser weil: Beide System laufen lokal auf deinem Rechner und somit funktionieren beide auch dann, wenn du mal keine Internetverbindung hast. Wenn eine Verbindung besteht, kannst du die Änderungen mit dem Server abgleichen.

Aussage falsch, weil: SVN ebenfalls lokal läuft und ebenfalls auch dann bestens funktioniert, wenn keine Internetverbindung besteht.

- ... CVS und SVN beide einen Server benötigen, den Du irgendwo installieren musst, zB. bei Dir zuhause.

Aussage falsch, weil: SVN keinen Server benötigt, den man irgendwo installieren muss.

Die Aussagen sind nur dann falsch, wenn Du davon ausgehst, dass Du Dich a) beim Entwickeln immer auf einen Rechner beschränken kannst und b) immer alleine arbeitest.

Ich weiß nicht, wie häufig das bei Dir der Fall ist, aber bei mir kommt a) bei jedem Projekt irgendwann der Zeitpunkt, an dem ich gerne vom Laptop aus arbeiten möchte oder auf der Uni im Labor oä. und b) arbeite ich an der überwiegenden Mehrzahl meiner Projekte nicht alleine, weswegen Kollegen der Verweis auf den USB-Stick, auf dem mein Repo liegt, nicht viel hilft.

Dravere: Dass der Einstieg mit Mercurial leichter ist, als mit Git, würde mich nicht wundern. Ich habe bis jetzt wenig mit Mercurial gemacht, früher aber häufig darcs verwendet. Um Git richtig gut verwenden zu können, ist IMO ein bisschen mehr Wissen über Interna nötig, als bei Mercurial oder darcs. Die beiden (besonders darcs) skalieren besser nach unten. (Die staging area bei Git zB. ist ein tolles Feature, war anfangs aber etwas verwirrend.

Wie gesagt, ob Git oder Mercurial halte ich für Geschmackssache; beide sind verteilt, schnell, haben kompakte Repos, brauchbares Branching und sind so zuverlässig, dass man seinen Tools wirklich trauen kann. (Bei Subversion mit BDB ist es verdammt leicht, sich versehentlich ein Repo zu zerschießen, was mir mit Git und Mercurial noch nie passiert ist.)

nman

RHBaum schrieb:

Unsere Anforderungen z.b.:
- Defizieles RechteManagment

Diffizil? Inwiefern?

(Ja, alles wo userspezifische Zugriffsrechte innerhalb eines Projekts für unterschiedliche Files unterschiedlich sein sollen, ist anstrengend. Meinst Du das?)

- Kommunikation ueber nur bestimmte protokolle fuer externe zugriffe. FTP/SFTP faellt raus wegen Sicherheitsapekte, direktzugriff (SSH, telnet ... ) faellt raus wegen Sicherheitsaspekte ... nfs/cifs(smb) no chance ... das einzige was geht ist http/https

SSH in Sachen Sicherheit mit telnet gleichzusetzen, finde ich schon hart.

SSH ist eine moderne Remote-Shell, die sich sehr gut für solche Aufgaben eignet. Ansonsten ist Schreibzugriff über HTTP in Git auch kein Problem.

Wenn ich bei einem so einen Project mal 3 Tage ned Comitte, bin ich hinterher locker schneller wenn ich meine Aenderungen verwerfe und in den aktuellen Stand komplett neu einpflege, als wie wenn ich die Kollisionen bearbeite ....

Aber doch nur deswegen, weil das Merging bei älteren Versionskontrollsystemen so mies ist. Ich höre oft "Branching ist doch ganz einfach" und das stimmt auch. Nur verwendet es niemand, weil das Merging so ein Riesenkrampf ist.

Moderne verteilte VCS haben für genau solche Einsatzzwecke richtig gutes Branching und Merging, das funktioniert wunderbar für solche Einsatzzwecke. Ist natürlich aber kein Ersatz dafür, hin und wieder miteinander zu reden.

Oberon_0

Als weitere verteilte SVN-Alternative gibt es noch Bazaar