KDE Switches to Subversion

Michael Pyne writes "It's official, after weeks of preparation, KDE has completed switching their source control repository from CVS to Subversion. KDE is one of the largest software projects to make the switch, and is the first major desktop environment to do so. Some of the goodies that CVS users are used to are still in the process of being switched over (including WebSVN), but everything seems to be working well so far." (The announcement of early April is no longer the operative statement.)

Comments

Why not everyone likes svn:

[Anonymous Coward]

Monolithic svn databases are vulnerable to irrecoverable corruption

Re:Differences

[Pete]

Subversion's really intended to be as close to a drop-in replacement for CVS as possible - except with most of the huge design flaws fixed.

The feature I most notice (I use Subversion at work, albeit with a fairly small dev team) is the ability to do handle file renames properly (preserving history). Atomic commits (of groups of files) are also nice.

There are lots of other important features of course, but I tend to use it just as a better CVS - which role it fills admirably.

I would love to see how well Insurrection works...

[Anonymous Coward]

I have build Insurrection, an enhanced web interface to Subversion, that is very closely tied to the way Subversion works. I would love to see how well it handles a repository as large as the KDE repository. (Plus I think it is a good tool, but then I wrote it :-)

You can play around with it at http://www.sinz.org/Michael.Sinz/Insurrection/

Note that I am still in somewhat active development but the code is also in active use. It can be checked out with:

• svn co http://svn.sinz.com:8000/svn/Web/trunk

Re:Differences

[Chris Kamel]

Check this for a detailed checklist of what each of the major version control systems support/doesn't support.

Re:Differences

[Anonymous Coward]

There are many...

The main one tends to be lack of tracking of file/directory renames. CVS does not really handle this at all while Subversion handles this very well.

Subversion also treats a commit of changes to multiple files as an atomic operation. This is a major benefit. You can easily see what all went into a specific commit (bug fix/etc) without trying to track down each file that it happened to. You also never have to worry about part of your commit being on the server and part of it not. It either is committed or it is not. CVS can not do that. (Well, beyond a single file that is)

Another major issue is the client/server relationship. Subversion has a very clean client/server interface. It is orthogonal, well designed, and relatively low overhead. CVS can not claim this to be the case. In fact, CVS's client/server features were bolted on after-the-fact and show it.

Subversion can work via HTTP/HTTPS protocols via an Apache plugin. In fact, it is not just HTTP but WebDAV and DeltaV protocol based, which means that there are other tools that can play with the repository as a auto-revisioned filesystem.

Subversion makes it possible to do some advanced web interfaces rather easily, such as the Insurrection http://insurrection.tigris.org/ does.

For me, once Subversion 1.1 came out there was no reason to look back at CVS other than legacy systems. (Subversion 1.0 was already better but it was 1.1 that finally put be over the edge.)

Re:Differences

[DarkDust]

What are the most important features that Subversion has and CVS hasn't? It's been a lot of buzz lately behind Subversion, but I didn't figure it out what CVS has that is so wrong/slow/bad for software versioning

• File/directory renaming. This is one of the most important things: you can easily move files around in a repository and thus rearrange your project directory structure. I'm forced to work on a big commercial project where we use CVS and the directory layout has grown like a cancer because some idiots couldn't get the layout clean in the first place and noone was able to correct it later (the CVS admin lacks the knowledge and the work necessary has become too big). This is a common CVS problem.
• Atomic commits.
• Cheap copies (which are used instead of tags and branches, more on this below).
• Optional WebDAV support.
• True binary file support (SVN only stores the deltas to previous versions while CVS has to store the complete file again if something changed... try versioning a 128MB binary file with CVS and watch your disk usage go up by 128MB with each commit).

There are two things that you'll find different when comming from CVS:

• The first is the fact that you don't version single files but the whole repository. This is very strange at first, but you'll quickly notice that it's much better than versioning single files as most of the time a source change like a feature implementation affects more than one file. With CVS you don't know that two files were changed at once and that these changes belong together: with SubVersion you instantly know because you see that at revision XY two files where changed.
• The other thing that seems odd is the "lack" of branches and tags like they're used in CVS: in CVS the repository file path stays the same while the working copy content is different according to the tag/branch. In SubVersion, you'll make a copy of a directory (in the repository) to start a branch. Thus the file path is different. I think the SubVersion way is cleaner and also more user/developer friendly but people that use CVS for years won't agree, I think ;-)

SubVersion as a whole has more clean, thought-out-design feel, IMHO. Being a former CVS user myself I guarantee you that after working with SubVersion for a while CVS feels a bit hacked together.

Re:windows cvs

[malloc]

Subversion has a client, but no server [for Windows].

What!? That is complete nonsense. Subversion has excellent and complete (client + server) cross-platform support. Linux, Windows, *BSD, MacOS X, Solaris -- you name it. They achieve this by using C and APR.

Maybe you should read HOWTO Setup A Server on Windows.

-Malloc