Ich hab cvs, svn, git, gnu arch, darcs, und hg ausprobiert. Letzteres (hg == Mercurial) ist das beste was ich soweit gesehen habe, schnell, einfach in der Bedienung und sehr stabil. darcs war nicht schlecht, leider zu langsam. git ist zu low-level fuer meinen Geschmack, svn ist aus meiner Sicht sogar schlimmer als CVS, viel zu schlechter Code (mind. 20kSLOC die unnoetig sind) und auch sonst zu der Zeit wo ich es genutzt habe (ca. 1.0.X Zeiten) viel zu instabil. Das BDB-Backend war der letzte Schrott, staendig musste ich die DB recovern wenn mehr als 1 Entwickler committed haben. Naja, und verteilte Repositories sind schonmal garnicht moeglich. Mercurial besteht aus weniger Code, als was in svn zu gut des Boesen ist.
@fghfh: Lies dir z.B mal ein paar Wikipedia-Artikel durch, zur Einführung http://de.wikipedia.org/wiki/Versionsverwaltung und dann such in der Wikipedia einfach mal nach den oben genannten, da gibts überall gute Artikel dazu - du wirst hier sicher keinen finden, der dir das erklärt anstatt das du dir das selber nachliest ;)
@arg: Mercurial ist zwar toll, auch Bazaar-NG ist z.B. nicht übel (wenn auch etwas langsamer als Mercurial) - aber SVN ist einfach verbreiteter, es gibt eine tolle Unterstützung für IDEs etc. - von daher werde ich, auch wenn andere Systeme evtl. besser sind, wohl bei SVN bleiben. Vielleicht gibts ja mal irgendwann eine Art Wrapper für IDEs, oder andersweitiger Einbindung..
es wäre vielleicht fair zu sagen, dass Subversion 1.0 schon eine ganze Weile her ist und nicht mehr als aktuell gelten kann. Weiter ist BDB schon lange nicht mehr das Backend-FS der Wahl. Default ist fsfs und läuft sehr stabil.
Total Physical Source Lines of Code (SLOC) = 489,529
Mercurial: sloccount mercurial-0.9.1
Totals grouped by language (dominant language first): python: 15887 (66.26%) tcl: 3297 (13.75%) sh: 3011 (12.56%) lisp: 967 (4.03%) ansic: 815 (3.40%)
Total Physical Source Lines of Code (SLOC) = 23,977
Dafuer das hg mit 5% des SVN-Codes mehr Features bietet, wesentlich schneller ist und dadurch viel wartbarer, muss in SVN etwas grundsaetzlich falsch sein.
Von thomas001 am Mo, 11. September 2006 um 17:15 #
oh man,komm mal aus der steinzeit raus,mit LOC wird schon lange nichtmehr umfang oder komplexitaet gemessen.... gabs nich mal ne thedailywtf geschichte wo sie extra alles auf ne neue zeile gemacht haben damit der LOC fanatische chef zufrieden ist? *g*
SLOC ist immernoch ein guter Indikator fuer Komplexitaet. Ich will daran nicht zuviel fest machen, aber 30.000 vs 500.000 ist ein signifikanter Unterschied, und bei svn ist definitiv nicht mehr Funktionalitaet feststellbar als bei Mercurial, sorry...
Von kuschelbaer am Di, 12. September 2006 um 10:58 #
definitiv nicht mehr Funktionalitaet feststellbar als bei Mercurial, sorry...
Wie kommts du darauf? Webdav-fähigkeit von Mercurial? Gibt es das? Wie schaut es mit einer API aus so das ich gegen Mecurial programmieren kann? Habe ich nicht entdecken können. Bietet Mercurial Locking?
Für mich hat svn deutlich mehr Funktionalität und ist universeller einsetzbar (unter anderem wegen der Benutzung von Apache APR etc.) Die Frage die sich stellt lautet wohl eher: Brauch ich das alles? Benötige ich ein DSCM mit den spezifischen Vor/Nachteilen oder bin ich mit einem CSCM besser bedient. Ciao, Kuschelbaer
Eingebauten WebDAV-Support gibt es nicht, das ist auch nicht Aufgabe eines VCM Systems. Man kann aber recht einfach via WebDAV auf hg zugreifen wenn das gewuenscht ist (Trennung von Uebtragungsprotokoll und eigentlichem Werkzeug sollte strikt sein, nicht so wie bei SVN, wo gleich noch ein WebServer eingebaut ist). Ich habe aber ein besseres Gefuehl via SSH (und im Gegensatz zu darcs wird bei hg nur eine Session fuer die ganze Uebertragung benoetigt). Die API von Mercurial kann entweder via python-Bindings verwendet werden oder ist implizit via hg-fork()'s gegeben, wozu braucht man mehr? Locking benoetigt Mercurial nicht, da Mercurial im Gegensatz zu SVN ein verteiltes VCM ist und kein zentrales. Jede Arbeitskopie ist ein Repository fuer sich, und patchsets koennen in beliebige Repositories gepusht werden, die das gleiche Root-Node Patchset enthalten.
Apache APR ist eine Abscheulichkeit, genauso wie Apache selbst... 1.x geht ja noch halbwegs, aber Apache 2.x ist wirklich fehlgesteuert. Klar ist die Frage ob man alles braucht oder nicht. Aber ich habe eben cvs, svn, darcs, gnu arch, git und hg _ernsthaft_ eingesetzt, und beurteile die Software nicht mit aus der Luft gegriffenen Argumenten, sondern tue einfach meine Erfahrung und mein Gefuehl kund. SVN ist wirklich die letzte Wahl fuer mich, die selbst weit nach CVS kommt...
Das soll aber kein Anstoss zum Flamen sein, ich hab mir halt Teile des SVN Codes angesehen, und war abgrundtief schockiert - wenn das wirklich eine ernsthafte und sichere Alternative zu CVS sein soll...
Von kuschelbaer am Di, 12. September 2006 um 11:45 #
Ja jedem seine Meinung. Deine Antwort zeigt mir, das du dich mit dem Thema beschäftigt hast, soweit es deine Anforderungen angeht. Das bedeutet aber lange nicht das Anforderungen anderer Leute nicht so wichtig sind. Locking geht nicht mit DSCM. Das ist schon klar. Auch mit einem CSCM(wie svn) braucht man kein Locking, es sei denn eine Anforderung erfordert das nicht gleichzeitige ändern an einer Dati:-( Sobald diese Anforderung steht, kann kein DSCM mehr eingesetzt werden. Wer tatsächlich mal mit CVS gearbeitet hat wird verstehen, warum SVN in der tat eine Weiterentwicklung ist. Ich ziehe es allen anderen kostenlosen SCMs vor. SVN bringt keinen Webserver mit, es erlaubt die Kommunikation mit dem Repository über HTTP(Doch dafür wird ein Webserver benötigt). Damit kommt es lesend über alle Firewalls. Nur beim schreiben muss gegebenenfalls HTTPS eingesetzt werden. Bevor wir uns falsch verstehen, aufgrund meiner zu erfüllenden Anforderungen kommt kein DSCM in Frage und bei den CSCM setze ich lieber auf ein Produkt das vom Entwickler eines guten Produktes stammt. Der Entwickler von CVS will mit SVN einen besseren Nachfolger schaffen und bekommt das auch hin. SVN ist schon produktiv einsetzbar, das sieht man alleine daran das grosse OpenSource Projekte SVN benutzen und sehr gut damit fahren. SVn entwickelt sich zu einem Standard eines CSCM. Vielleicht solltest du dir die Version 1.4 von SVN doch mal anschauen.
Noch mal zu Mercury: Das käme für mich nur in Frage, wenn meine Anforderungen es zuliessen. Hast du eigentlich Erfahrung mit Mercury in einem Projekt mit 100 Entwickler verteilt über mehrere Standorte? Ciao, Kuschelbaer
Nein, ich kenne kein Projekt das mehr als 100 Entwickler hat und mit Mercurial arbeitet. Es gibt aber Projekte die in dieser Groessenordnung mit git arbeiten (und es gibt 1:1 Mappings von git nach hg und zurueck).
Klar, wenn mehrere Personen an der gleichen Datei arbeiten kommt es zu Problemen bei verteilten VCMs, aber ob Locking da wirklich eine Hilfe ist, vage ich zu bezweifeln (oftmals bemerken Entwickler ja erst dann den Lock, wenn es zu spaet ist, wenn also schon Zeit investiert wurde und beim commit sieht man, das ein anderer Entwickler an der selbem Datei arbeitet - fuer mich ist das weniger vorteilhaft, als nun patchsets zu mergen in einem DVCM)... das mag aber Geschmackssache sein.
Ich muss in einem anderen Projekt gezwungenermassen mit SVN arbeiten, deshalb kenne ich die 1.4er Version bereits, aber ich misse den verteilten VCM Charakter, den ich bereits gewoehnt bin.
Nee, ich bezweifel mit Nachdruck das C eine niedrige Code-Dichte hat, der Grund ist eher dass die C-Programmierer von SVN keine Ahnung von C haben. Eines der Hauptprobleme ist, dass viele C-Programmierer von anderen Programmiersprachen kommen und nie Code von wahren C-Programmierern wie Ken Thompson oder K & R studiert haben (selbst mancher Linux Entwickler ist da eine gute Quelle, Alan Cox' Code ist sehr empfehlenswert btw.). Mir ist beim studieren von C Sourcen oft aufgefallen, dass gerade die Entwickler die irgendwie aus der OOP-Welt in die C-Welt stroemen eine Neigung dazu haben, Abstraktionen zu konstruieren, die unnoetig viel Code notwendig machen, also statt sowas wie
zu verwenden (was der Weg von wahren C Programmierern ist), werden generische Listen, Heaps, Stacks, und andere Datenstrukturen implementiert. Dadurch wird zwar der Vorteil gewonnen, dass man bestimmte Dinge (wie add/remove) nur an einer Stelle implementiert, aber das ganze Datenmodell wird deutlich komplexer, da man generisch an allen Stellen auf konkrete Typen casten muss (und dabei gleich noch die statische Typ-Pruefung beim Compilieren ueber Bord wirft und sich ganz subtile Fehler einfangen kann, wenn es nicht gewuszt wird wie)...
Ein ganz einfacher Beweis zur Widerlegung Deiner These ist zB der plan9port (enthaelt ein komplettes Plan 9 userland + grafische Tools, diverse libraries, vollstaendiger UTF-8 Support, in weniger C Code als Subversion (s.u.)). Ausserdem werden Dir Vergleiche von fefe's dietlibc zur GNU libc auch deutliche Unterschiede aufzeigen...
Subversion ist zum heutigen Zeitpunkt eigentlich inzwischen glücklicherweise in allen großen IDEs integriert.
Für Eclispe z.B. gibt es ein exzellentes Plugin namens SubClipse, das ist auch sicherlich stabil, das gibts schon ne Weile und kommt von den Entwicklern von SVN selber -> http://subclipse.tigris.org/
Für KDevelop gibts auch ein Plugin, wenn ich es recht weiß, war es bei mir schon von Haus aus dabei
Für KDE gibts was zur Integration in den Konqueror, für Gnome denke ich doch mal auch bzgl. Nautilus.
Von Felix Schwarz am Mo, 11. September 2006 um 22:02 #
Wobei Subclipse meiner Meinung nach noch deutlich schlechter ist als das CVS-Plugin: - Schlechte Fortschrittsanzeigen (z.B. wird beim Commit 99% angezeigt, wenn der File Content geschickt wird, obwohl das u.U. deutlich länger dauert als die Operationen vorher). - Sehr schlechte Interaktivität (ein Commit kann nicht abgebrochen werden) - diverse Bugs, bei denen man mit dem Kommandozeilen-Client ran muss, dabei Subclipse wieder funktioniert (liegt eventuell an JavaSVN).
Von Felix Schwarz am Mo, 11. September 2006 um 22:07 #
Wobei von Subversive eher abraten würde. Ich hatte mehrere fiese Bugs (so hat Subversive nach dem Anklicken von "Share Project" bei mir Eclipse manchmal in einem Zustand hinterlassen, so dass das Programm nicht mehr auf irgendwelche Mausklicks reagierte und gekillt werden musste) und bin dann doch wieder zu Subclipse gewechselt, trotz dessen Schwächen.
Von Entwickler am Mo, 11. September 2006 um 15:20 #
ist immer noch die Referenz in Sachen Quellcodeverwaltung. cvs, svn,... das Zeug ist einfach nur kaputt und integriert sich in keine vernünftige IDE sauber ein.
> integriert sich in keine vernünftige IDE sauber ein Hmm, Mist. Und ich dachte, nachdem es sowas gibt, wäre das Visual Studio auf dem besten Weg, eine vernünftige IDE zu werden. :(
Visual Source Safe ist der letzte Müll und total veraltet, ich kenne niemanden der VSS einsetzt. VSS bricht bei großen Repositorys regelmäßig auseinander. Ich kennen zig Firmen,Leute, die VSS mit ihrem MSDN Abo mitbekommen und trotzdem nicht benützen.
Es reicht etwas zu googlen und schon findest du massig Infos wie diese:
#### Visual SourceSafe (called VSS in the following text) has a few disadvantages against other versioning software. VSS works on file system level using shares, which leads to an inability to access the repository from different time zones or from the internet. Expensive third-party software is required to add such functionality.
Large software projects slow SourceSafe down. Branches are rather simply implemented and not much of practical use. Besides that VSS has a chaotic repository management. Fragments of source are scattered over several files with vacuous names, which makes a manual restauration of the repository impossible.
VSS also does not allow concurrent access to a project. If somebody checked out a file, the other developers have no means to checkout and change this file as well. CVS, on the other hand, allows concurrent access to files by several developers. It will automatically merge all modifications later.
Furthermore, VSS requires Windows, taking you the possibility to use other operating systems for development. CVS can be accessed from virtually any operating system, though.
Finally it is also a question of cost, because a VSS licence isn't quite cheap, bound to a single user, and required third-party tools take another licence to be paid. So you are paying a lot of money for a comparatively moderate piece of software.
CVS solves all those issues. The software has been proven in the professional software development for many years. It is mature, reliable and free of charge. ####
Unser Entwickler schient ein richtiger Profi zu sein. Vielleicht kennt er nichts anderes außer VSS? Aber er kann sich ja mal diese Seite anschauen, da kann man sich ein Bild davon machen, das die "Referenz VSS" wohl eher den unteren Anker darstellt:
Letzteres (hg == Mercurial) ist das beste was ich soweit gesehen habe, schnell, einfach in der Bedienung und sehr stabil. darcs war nicht schlecht, leider zu langsam. git ist zu low-level fuer meinen Geschmack, svn ist aus meiner Sicht sogar schlimmer als CVS, viel zu schlechter Code (mind. 20kSLOC die unnoetig sind) und auch sonst zu der Zeit wo ich es genutzt habe (ca. 1.0.X Zeiten) viel zu instabil. Das BDB-Backend war der letzte Schrott, staendig musste ich die DB recovern wenn mehr als 1 Entwickler committed haben. Naja, und verteilte Repositories sind schonmal garnicht moeglich. Mercurial besteht aus weniger Code, als was in svn zu gut des Boesen ist.
[0] http://www.selenic.com/mercurial
@arg: Mercurial ist zwar toll, auch Bazaar-NG ist z.B. nicht übel (wenn auch etwas langsamer als Mercurial) - aber SVN ist einfach verbreiteter, es gibt eine tolle Unterstützung für IDEs etc. - von daher werde ich, auch wenn andere Systeme evtl. besser sind, wohl bei SVN bleiben. Vielleicht gibts ja mal irgendwann eine Art Wrapper für IDEs, oder andersweitiger Einbindung..
es wäre vielleicht fair zu sagen, dass Subversion 1.0 schon eine ganze Weile her ist und nicht mehr als aktuell gelten kann. Weiter ist BDB schon lange nicht mehr das Backend-FS der Wahl. Default ist fsfs und läuft sehr stabil.
Subversion ist eine gute OSS.
Gruß
Subversion: sloccount subversion-1.4.0/
Totals grouped by language (dominant language first):
ansic: 405899 (82.92%)
python: 37805 (7.72%)
sh: 12280 (2.51%)
cpp: 9603 (1.96%)
ruby: 8313 (1.70%)
perl: 7194 (1.47%)
java: 4576 (0.93%)
lisp: 3859 (0.79%)
Total Physical Source Lines of Code (SLOC) = 489,529
Mercurial: sloccount mercurial-0.9.1
Totals grouped by language (dominant language first):
python: 15887 (66.26%)
tcl: 3297 (13.75%)
sh: 3011 (12.56%)
lisp: 967 (4.03%)
ansic: 815 (3.40%)
Total Physical Source Lines of Code (SLOC) = 23,977
Dafuer das hg mit 5% des SVN-Codes mehr Features bietet, wesentlich schneller ist und dadurch viel wartbarer, muss in SVN etwas grundsaetzlich falsch sein.
[0] http://www.dwheeler.com/sloc/
gabs nich mal ne thedailywtf geschichte wo sie extra alles auf ne neue zeile gemacht haben damit der LOC fanatische chef zufrieden ist? *g*
Wie kommts du darauf? Webdav-fähigkeit von Mercurial? Gibt es das?
Wie schaut es mit einer API aus so das ich gegen Mecurial programmieren kann? Habe ich nicht entdecken können.
Bietet Mercurial Locking?
Für mich hat svn deutlich mehr Funktionalität und ist universeller einsetzbar (unter anderem wegen der Benutzung von Apache APR etc.) Die Frage die sich stellt lautet wohl eher: Brauch ich das alles? Benötige ich ein DSCM mit den spezifischen Vor/Nachteilen oder bin ich mit einem CSCM besser bedient.
Ciao,
Kuschelbaer
Die API von Mercurial kann entweder via python-Bindings verwendet werden oder ist implizit via hg-fork()'s gegeben, wozu braucht man mehr?
Locking benoetigt Mercurial nicht, da Mercurial im Gegensatz zu SVN ein verteiltes VCM ist und kein zentrales. Jede Arbeitskopie ist ein Repository fuer sich, und patchsets koennen in beliebige Repositories gepusht werden, die das gleiche Root-Node Patchset enthalten.
Apache APR ist eine Abscheulichkeit, genauso wie Apache selbst... 1.x geht ja noch halbwegs, aber Apache 2.x ist wirklich fehlgesteuert. Klar ist die Frage ob man alles braucht oder nicht. Aber ich habe eben cvs, svn, darcs, gnu arch, git und hg _ernsthaft_ eingesetzt, und beurteile die Software nicht mit aus der Luft gegriffenen Argumenten, sondern tue einfach meine Erfahrung und mein Gefuehl kund. SVN ist wirklich die letzte Wahl fuer mich, die selbst weit nach CVS kommt...
Das soll aber kein Anstoss zum Flamen sein, ich hab mir halt Teile des SVN Codes angesehen, und war abgrundtief schockiert - wenn das wirklich eine ernsthafte und sichere Alternative zu CVS sein soll...
Locking geht nicht mit DSCM. Das ist schon klar. Auch mit einem CSCM(wie svn) braucht man kein Locking, es sei denn eine Anforderung erfordert das nicht gleichzeitige ändern an einer Dati:-( Sobald diese Anforderung steht, kann kein DSCM mehr eingesetzt werden.
Wer tatsächlich mal mit CVS gearbeitet hat wird verstehen, warum SVN in der tat eine Weiterentwicklung ist. Ich ziehe es allen anderen kostenlosen SCMs vor.
SVN bringt keinen Webserver mit, es erlaubt die Kommunikation mit dem Repository über HTTP(Doch dafür wird ein Webserver benötigt). Damit kommt es lesend über alle Firewalls. Nur beim schreiben muss gegebenenfalls HTTPS eingesetzt werden.
Bevor wir uns falsch verstehen, aufgrund meiner zu erfüllenden Anforderungen kommt kein DSCM in Frage und bei den CSCM setze ich lieber auf ein Produkt das vom Entwickler eines guten Produktes stammt. Der Entwickler von CVS will mit SVN einen besseren Nachfolger schaffen und bekommt das auch hin. SVN ist schon produktiv einsetzbar, das sieht man alleine daran das grosse OpenSource Projekte SVN benutzen und sehr gut damit fahren. SVn entwickelt sich zu einem Standard eines CSCM.
Vielleicht solltest du dir die Version 1.4 von SVN doch mal anschauen.
Noch mal zu Mercury: Das käme für mich nur in Frage, wenn meine Anforderungen es zuliessen. Hast du eigentlich Erfahrung mit Mercury in einem Projekt mit 100 Entwickler verteilt über mehrere Standorte?
Ciao,
Kuschelbaer
Nein, ich kenne kein Projekt das mehr als 100 Entwickler hat und mit Mercurial arbeitet. Es gibt aber Projekte die in dieser Groessenordnung mit git arbeiten (und es gibt 1:1 Mappings von git nach hg und zurueck).
Klar, wenn mehrere Personen an der gleichen Datei arbeiten kommt es zu Problemen bei verteilten VCMs, aber ob Locking da wirklich eine Hilfe ist, vage ich zu bezweifeln (oftmals bemerken Entwickler ja erst dann den Lock, wenn es zu spaet ist, wenn also schon Zeit investiert wurde und beim commit sieht man, das ein anderer Entwickler an der selbem Datei arbeitet - fuer mich ist das weniger vorteilhaft, als nun patchsets zu mergen in einem DVCM)... das mag aber Geschmackssache sein.
Ich muss in einem anderen Projekt gezwungenermassen mit SVN arbeiten, deshalb kenne ich die 1.4er Version bereits, aber ich misse den verteilten VCM Charakter, den ich bereits gewoehnt bin.
rpm.org
opensolaris.org
alsa
xen
grml.org
...
projekte mit synchronized mercurial mirror:
linux kernel
dragonfly bsd
freebsd
mutt
emacs
...
is doch fuer die groesse die mercurial hat garnicht so schlecht
http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial
ansic: 405899 (82.92%)
python: 15887 (66.26%)
was wohl eher ein indikator fuer die niedrige code-dichte von C gegenueber python ist, als fuer irgendwas anderes.
String operationen etc. sind nunmal in scriptsprachen kompakter darstellbar. Und was ist wohl die hauptaufgabe von svn & co?
typedef struct Foo;
struct Foo {
int bla;
Foo *next;
};
zu verwenden (was der Weg von wahren C Programmierern ist), werden generische Listen, Heaps, Stacks, und andere Datenstrukturen implementiert. Dadurch wird zwar der Vorteil gewonnen, dass man bestimmte Dinge (wie add/remove) nur an einer Stelle implementiert, aber das ganze Datenmodell wird deutlich komplexer, da man generisch an allen Stellen auf konkrete Typen casten muss (und dabei gleich noch die statische Typ-Pruefung beim Compilieren ueber Bord wirft und sich ganz subtile Fehler einfangen kann, wenn es nicht gewuszt wird wie)...
Ein ganz einfacher Beweis zur Widerlegung Deiner These ist zB der plan9port (enthaelt ein komplettes Plan 9 userland + grafische Tools, diverse libraries, vollstaendiger UTF-8 Support, in weniger C Code als Subversion (s.u.)). Ausserdem werden Dir Vergleiche von fefe's dietlibc zur GNU libc auch deutliche Unterschiede aufzeigen...
[0] http://swtch.com/plan9port/plan9port.tgz
[1] http://www.fefe.de/dietlibc/
Wie siehts mit Subversion aus ? Gibts stabile Plugins für die IDEs ?
Und wie sieht das Zusammenspiel von Subversion und guten Editoren ( VIM, Emacs) aus ?
Für Eclispe z.B. gibt es ein exzellentes Plugin namens SubClipse, das ist auch sicherlich stabil, das gibts schon ne Weile und kommt von den Entwicklern von SVN selber -> http://subclipse.tigris.org/
Für KDevelop gibts auch ein Plugin, wenn ich es recht weiß, war es bei mir schon von Haus aus dabei
Für KDE gibts was zur Integration in den Konqueror, für Gnome denke ich doch mal auch bzgl. Nautilus.
- Schlechte Fortschrittsanzeigen (z.B. wird beim Commit 99% angezeigt, wenn der File Content geschickt wird, obwohl das u.U. deutlich länger dauert als die Operationen vorher).
- Sehr schlechte Interaktivität (ein Commit kann nicht abgebrochen werden)
- diverse Bugs, bei denen man mit dem Kommandozeilen-Client ran muss, dabei Subclipse wieder funktioniert (liegt eventuell an JavaSVN).
fs
fs
cvs, svn,... das Zeug ist einfach nur kaputt und integriert sich in keine vernünftige IDE sauber ein.
Hmm, Mist. Und ich dachte, nachdem es sowas gibt, wäre das Visual Studio auf dem besten Weg, eine vernünftige IDE zu werden. :(
lg
Erik
Es reicht etwas zu googlen und schon findest du massig Infos wie diese:
####
Visual SourceSafe (called VSS in the following text) has a few disadvantages against other versioning software. VSS works on file system level using shares, which leads to an inability to access the repository from different time zones or from the internet. Expensive third-party software is required to add such functionality.
Large software projects slow SourceSafe down. Branches are rather simply implemented and not much of practical use. Besides that VSS has a chaotic repository management. Fragments of source are scattered over several files with vacuous names, which makes a manual restauration of the repository impossible.
VSS also does not allow concurrent access to a project. If somebody checked out a file, the other developers have no means to checkout and change this file as well. CVS, on the other hand, allows concurrent access to files by several developers. It will automatically merge all modifications later.
Furthermore, VSS requires Windows, taking you the possibility to use other operating systems for development. CVS can be accessed from virtually any operating system, though.
Finally it is also a question of cost, because a VSS licence isn't quite cheap, bound to a single user, and required third-party tools take another licence to be paid. So you are paying a lot of money for a comparatively moderate piece of software.
CVS solves all those issues. The software has been proven in the professional software development for many years. It is mature, reliable and free of charge.
####
Gruß, die Tendenz
http://better-scm.berlios.de/comparison/comparison.html