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:Why not everyone likes svn:

[DarkDust]

If you're scared by the BDB backend then use the FSFS backend which is a filesystem based backend, like CVS uses RCS files.

We're using SubVersion for over two years now, versioning our in-house Linux distribution with which we're doing our products and we've never had any data loss (though we had some trouble with BDB back in the 0.xx days).

Re:Why not everyone likes svn:

[limbostar]

But while using the Subversion client, you don't have to care what backend the project managers are using. If the project database crashes, it's not your fault as a user.

If you're really super ultra paranoid, you could set up your own svn repository with your favorite backend, sync it up with KDE's project, and work from there, but then you're just making trouble for yourself.

SVN in client mode uses .svn directories (similar to CVS directories) with XML files and such to manage your local copy. Those big bad BDBs never come near you unless you're managing the repository.

successor to CVS

[moz25]

As I understand, subversion was more or less designed to be the successor (and replacement) of CVS. It's not a big surprise then that switching is a major issue. The users are already used to its methodology (contrary to e.g. linux kernel developers).

Re:Differences

[dos_dude]

Apparently, subversion allows you to rename files (which is a clumsy process in cvs). It's also able to keep track of directories themselves. cvs doesn't care about diretories, only about files.

There are lots more differences though, but the two I mentionend certainly sound like they made life a little easier.

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:Subversion + trac

[tuxpert]

Although trac is quite good and integrates well with SubVersion, it has a few disadvantages, the main one being no support for multiple projects.

Scarab, the open-source bug tracking tool that CollabNet's commercial offering uses and GForge, although cumbersome to setup are IMHO better alternatives if you're looking for bug-tracking tools to use along with SubVersion

--
Ravi

TortoiseSVN

[Mustang Matt]

This is one of the best windows based svn clients I've seen.

http://tortoisesvn.tigris.org/

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:GUI frontend for SVN

[slavemowgli]

Did you look into RapidSVN? I haven't tried it myself, but it may be an interesting alternative to TortoiseSVN if you want support for platforms other than windows.

There's also a Subversion plugin for Eclipse, in case you're using that.

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:Subversion + trac

[Pete]

I understand that Trac support for multiple projects (along with a few other features) is due soon - I believe as part of the upcoming 0.9 release.

Thanks for the pointers re: Scarab and GForge though, I'll have a look at them. Always nice to keep up-to-date with the alternatives. :)

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

Re:A much needed switch

[flink]

If you setup SSL on the web server, they should be able to check out just fine using an https:/// url, as the firewall will have no idea what PROPFINDs are flying around.