January 6th, 2008
I’m trying to add my projects to SVN (subversion), open source source control system. Installing and working with it is typical experience when using open source tools. There is no “download – install – use” procedure. As with other open source tools, you need to study it for some time, read some tutorials and guides and prepare yourself to work with it instead waiting for it to do work for you. And it’s used from command line, naturally. With some patience and additional tools like TortoiseSVN it’s not big deal to install and use it.
I’m writing this as VSS (Visual Source Safe) user. My team at work is using VSS and although we are aware of problems other teams had using it, I don’t think we’ll switch to something else in the near future. Somehow we’ve grown with VSS, using it for years without problems. I’ll try to use SVN at home, and write about experiences so i could eventually be ready to set it up for my team at work.
File locks
In VSS, if you want to edit a file, this file will be locked for every other user. If somebody else is editing it, you can only read it, editing is disabled. Of course, you can remove read only property from file, edit it anyway and merge it later, but this isn’t the recommended procedure and it’s discouraged.
In SVN, procedure is completely opposite. Everyone can get latest version and edit it as they want. If somebody already changed the file you want to commit you are asked to merge the changes.
What is better? Though question. In my opinion SVN’s style encourages you to talk to your coworkers and plan your project’s resources. Let say, you have a project with 100 source files and 20 programmers. If every coder want to work on few files, there’s big chance that only half of this twenty programmers can lock all their files while they working. That’s the point where SVN’s style is better. Team should organize their work before they start to write any code. When they agree and stick to the plan, there could be no problems with merging.
File sharing between projects
This is the most problematic part in transition from VSS to SVN. In my team, file sharing is extensively used. We have many projects and some of them share modules or classes. Common set of functions is in external class library, where it should be, but for some functions it’s more convenient to just share them between projects. Second case when we share files is when we customize the project for some special case. We don’t modify the main repository, rather we create the new project and branch only the files which will be different and share all other files. If we find some bug in shared file and correct it, both projects will get the updated version immediately. If such behaviour gets into your habit, it’s easy to think about it as the right and only way.
I was somewhat dismayed when i saw there is no file sharing in SVN. How could that be? If it’s better then VSS, how can it miss such an important and convenient feature. We’ll could never work without file sharing, whole team is relaying on it. Then i started to think about it. Once, we agreed that enumerator names needs to be changed. When it was convenient time for me, i changed them in my project, checked in the changes and inform everybody about it. When other programmer got the last version or his project, it was broken all over. Sooner or later, whatever source control system we used, he would need to take this changed enumerators. Day before some big release was really bad time to worry about broken namespaces. If we worked in SVN and did not used this feature, he would take the changed version after the release, with more time on his hands. It can be said i chopped down the tree while others were standing on its branches.
So it’s not about worse or better way, to have file sharing or not. It’s about organizing your team about provided features. File sharing is very nice feature but it can bring big problems when one wrong step is immediately propagated to every project. Working without it requires more work and team collaboration but you’ll always have the versions you really want.
One Response to “VSS to SVN”
April 27th, 2008 at 4:09
The core Subversion package is relatively easy to install (via a linux distribution’s package manager, or on Windows using the .exe installer.) Like most open-source tools, it has a command line interface, and can be tough to configure correctly. (Especially when setting up Apache on Windows to use the svn DAV module.)
TortoiseSVN is a very functional, reliable tool for Windows users; there are also a few VS plugins that provide a level of integration similar to that of VSS. AnkhSvn is reasonably functional and free; VisualSVN (visualsvn.com) is somewhat more reliable (it’s based on TortoiseSVN), but is a commercial product. (Well worth the $49, IMO) VisualSVN also provides a server component for Windows, which automates the installation and provides an MMC-based configuration tool. It supports SSL and Windows user authentication, and best of all, VisualSVN Server is free.
Subversion supports file locking quite easily; there are lock/unlock commands (also exposed in the GUI tools) which allow a file to be locked by a specific user; commits will be rejected until the file is unlocked. For problematic files (such as binary files) there is a “needs-lock” property that can be set for a file, which requires the file be locked before a commit is allowed. (Unlike VSS, if someone goes on vacation with a file locked, anyone can forcibly override the lock. Since any rouge changes can easily be reverted, this isn’t a significant security issue.)
Subversion does in fact support file sharing via the externals feature. “svn:externals” is a property that can be applied to folders; when a folder with this property set is checked out or updated, Subversion automatically reads this property and checks out/updates the specified projects (elsewhere in the same repository or in a different repository altogether) into subfolders.
Unlike VSS, this functions on folders, not individual files; there is no way to share a single file in SVN without putting it in it’s own folder. (IMO, sharing individual files is a bad idea anyway; better to share a complete library, as this induces looser coupling between projects.) We use this with third-party libraries; we check either the source (if we have it) or the binaries (if we don’t) into a separate project, and include it in other projects via Externals. You can also lock an external folder to a specific revision of it’s target repository with a parameter in the externals property, similar to the VSS “pin” feature. (Again, folders only, and it affects the entire subtree.)