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

Obligatory

[Anonymous Coward]

Kongradulations!

I truly wished they have given a different name.

[cabazorro]

My managers simply refuse to use anything proposed by us, the development team, and named subversion.

A much needed switch

[CastrTroy]

Its nice to see them making the switch. Having used both Subversion and CVS, I have to say that Subversion is much better. I hope more projects continue to do the same. Its amazing that CVS has lasted as long as it has.

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.

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:

[Speare]

ISTR TLAs give ROI over RSI, YMMV, HTH.

Re:Why not everyone likes svn:

[GuidoW]

This is why subversion has the svn dump command (or was it svnadmin dump or svndump? Well, it doesn't really matter) that you can use to do backups of your repository to _plaintext_ files, just like you would use pg_dump to backup your postgresql database.

Obviously, if you don't use the feature, it's pretty useless, but, hey, how often has it been pointed out that every serious project that uses computers needs a good backup strategy?

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.

More switching! More, more!

[Pete]

Great!

Now when are they going to be switching from Bugzilla to Trac?

(insert ha-ha-only-serious-cos-Bugzilla-scares-me smiley here)

Re:More switching! More, more!

[Pete]

Purely because I feel the UI is complicated. Of course I've mainly dealt with it on hideously large and complex projects like KDE and Mozilla, so the complexity of the UI may simply be a function of the project's complexity (or, more specifically, a function of Mozilla's complexity, as it was originally designed for Mozilla).

Note that I'm not meaning to slag off Bugzilla at all - it does the job and does it well, as far as I understand. But I wouldn't want to use it for the kind of software I work on (much much smaller and simpler than Moz).

My team is using a combination of Trac and Mantis at the moment - my boss likes Mantis better as a pure bugtracker, but I'm hoping to convert him after Trac 0.9. :)

Subversion + trac

[gregmac]

I recently switched my internal development from CVS to Subversion, and use trac (there site seems to be down right now) as a front end to it all. Trac is a web based interface (written in python) that is a combination wiki, bug tracker, source viewer, changelog and milestone tracker. It has some amazingly cool features, like the ability to put wiki markup anywhere.

Using a wiki for documenting code is somewhat handy, but what's even better is the wiki extensions trac adds. You can type "This is related to bug #236" and it will make it a link to that bug. The cool part is, you can do that anywhere -- such as an svn commit message. (There's also ways to link to milestones, revision numbers, etc)

I originally switched to subversion for the big features - the ability to move files/directories, and the simple (compared to cvs) tagging/branching support. Trac just made it that much better.

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

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. :)

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.

This is what happens...

[gbulmash]

...when you let geeks name products.

Of course, Microsoft is coming out with their own alternative. It's called Coercion.

- Greg

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.

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:I truly wished they have given a different name

[dubl-u]

My managers simply refuse to use anything proposed by us, the development team, and named subversion.

Good that you mentioned it. for $50k a year, I'm glad to license them my own version control system, "Rule The Developers With an Iron Fist". It's actually just Subversion and Trac in a box with a pretty logo and some marketing collateral. Plus, a guy with a nice suit and good hair will come and spend two hours explaining things to them in short words and bullet points.

Or they can get the deluxe version for $100k per year, where the guy with good hair will also take them golfing and out to dinner.

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

Re:I truly wished they have given a different name

[killjoe]

" My managers simply refuse to use anything proposed by us, the development team, and named subversion."

For the umpteenth time people. When you say things like this name your company. We all want to make sure we don't have ny stock in companies with this kind of management.

WTF

[eldacan]

The GNOME people are probably breaking out the champagne at this point. :-(

Excuse me!? Please don't spread the disgusting idea that GNOME people would rejoice at hundreds of FOSS developers losing their work.

There may be many "trolls" among GNOME and KDE users, but there are many intelligent people among the devs, who collaborate through freedesktop.org and even joke together, like on April 1st when they made planet.gnome.org point to planetkde.org and vice versa.

Re:Differences

[Woody77]

Price difference. Perforce was simply not an option for my small company. Subversion, on the other hand, is just as easy on the pocket-book as CVS.