Subversion: unbeatable sourcecontrol.

I'm now almost done reading the docs of Subversion, and I can only say: this is open source done right, and when open source is done right, it's unbeatable by any software vendor. The system breaths quality, well thought out design and passion for software engineering. The documentation is very good, it reads like a novel. The win32 explorer plug-in (TortoiseSVN) is also very good, and offers a rich quality of services. Subversion has two more things to offer: it's free and it runs on a wide range of platforms (Win32, *BSD, Unix, Linux, MacOS X).

Often open source software is lacking in one area or the other: features are narrowed down to what the initial developers thought would be great, design is often applied 'ad-hoc' and documentation comes in the form of the sourcecode itself. Not with Subversion. The documentation, the installer, the amount of work that has been put into the design, it all screams: professional software. The quality it offers is the quality of a commercial toolkit.

I'm one of those happy few *knock on serious wood* who hasn't run into Visual Sourcesafe problems that often however some things get annoying: because of the big trees of code I have to work with, loading these projects into Visual Studio.NET takes ages. Three other things that get annoying (already are ;)) are: files are read-only on disk, merging back complete branches is a pain (you have to merge file by file) and I can't exclude one or two projects in my solution from source-control. Especially that last one is bugging me the most, because sometimes projects are completely created using code generation and I don't want generated code polluting my VSS database, since these might change often, creating lots of history records in VSS and which make the system utterly slow.

For VSS veterans, Subversion can be weird at first because it uses a different model for sourcecontrol: you don't work directly on the repository (lock a file there by checking it out, edit it, check it in), you work on your local copy and set commands there what should happen to the repository copy of that set of files and directories. However because the documentation is excellent, you are guided very smoothly through the steps of understanding this different model and you'll learn very quickly what the advantages of this model are and which pitfalls to avoid.

One thing subversion doesn't have is sharing: change 1 file and all projects sharing that file have the new version. This can be handy when you have a web project with for example asp files which is shared by a number of websites. It is a feature I use for my ASP 3.0 based administrator GUI for our CMS: every website has a shared copy of that administrator GUI, so keeping them in sync, sourcecontrol wise, is not that hard. You can of course work around this with the more advanced Subversion commands, but because the model is about local copies and not 'just' the central server, the actual sharing functionality can't be re-created for 100%. This is not a disadvantage per se, as VS.NET's integration with SCC providers is limited in this too: you can't simply share a project in your solution that's also in another solution: VS.NET gets confused and it results in having 2 copies of the same project in the sourcecontrol database.

Am I exited about this new sourcecontrol system? Absolutely. When the project just started, it was Linux only and I felt disappointed, however as it turned out, it's cross platform and works perfectly, no Cygwin libs needed, no gcc compiles required, it comes with a nice win32 installer and .chm packed docs. With this kind of quality offered for free on a lot of platforms, thus a lot of exposure, people who use it, advice others etc., it is a tough call for ISV's who try to make a living selling sourcecontrol systems. I hope for the fine folks at Sourcegear, their product, Vault, has enough USP's to keep them in the market.

8 Comments

  • Subversion looks perfect for my homebrewn projects, so this night I gave it a try. It's almost perfect except one thing: VS.NET chokes on the .svn folder in the web project directories ('unable to read project information'). AAARRGGHHH!!! Why can't we have directory names starting with a dot? Note that this only applies to web(service) projects. Other projects work fine.

  • Martijin: I've experienced this same problem. Its more of a VS.NET/FPSE issue than an SVN issue. If you're working on web projects locally or across a file share, you can get around this by converting it to a regular class library project. I have some docementation on how to do this that i've compiled from various sources on the internet about how to do this. I can email it to anyone interested. See my URL for my email address. I guess if you have to work through FPSE, you're SOL for now.

  • Does it integrate nicely with VS.NET (as VSS does)?



    Thanks,

    Deyan Petrov

  • It only chokes for web projects. Local projects work fine.

  • hmmm... the only project i personally tested a .sgvault based state folder was a c# web service app.



    about 4 months into the project, we were finally able to start using vault to develop vault.



    as memory serves, the vs.net 2002 ide integration component was having problems with the .sgvault state folders. that was enough to warrant an immediate change, so the implementation using .sgvault was never really tested on other projects due to the short life of that naming convention.

  • what I wonder is (haven't tested it as I don't have a webproject under subversion at the moment), is the choking of vs.net only happening when you switch on 'view all files' in solution explorer? Or is this 'always' happening?

  • frans:



    please post your findings.



    its been such a long time, my memory of the problem is a little foggy. but i believe it had something to do with iis not allowing sub-folders to start w/ a period or something similar to that.

  • I was actually using Vault for my personal projects before I discovered Subversion. The main reason that I switched was because Vault was too slow and over the top for me - while I like the fact that it uses SQL Server, I definitely don't need web access for source control. Subversion is simple, and it just plain works. You definitely can't complain about that.

Comments have been disabled for this content.