Phine Solutions web work notes

CVS has always been my choice of source control tool. It does what is does and I have always been happy about it. However recently I moved my source code repository from an online server to a home machine, and had an opportunity to look into Subversion, the newer source control system that has been adopted by more and more developers.

I consider Subversion has these major advantages over CVS:

• Since it is the new kid on the block there are more interests to maintain and develop it, and also there are a lot more 3rd party client tools.
• Completely designed to be suitable for all file types. CVS was originally designed for text files only so there are some limitations or hurdles when you store binary or unicode files.
• Renaming a file or directory is as easy as just “renaming” it. In CVS, you have to delete, add with new name and commit. For a developer like me who can’t make up my mind when naming files and directories, this one is a keeper.
• More ways to access repository. From native svn server to ssh and http(s), subversion has more ways to connect to, and therefore, more ways to bypass a firewall that blocks certain ports.
• More clients available. Have I mentioned this in the first point? During my years of using CVS I only managed to find two legit GUI client: TortoiseCVS and WinCVS, other than the command line and IDE plugin. Subversion has a lot more in this department.
• Some other pros like atomic commit and directory versioning are also good but kind of trivial for me.

Now one biggest “con”, considered by some, is the absence of “tagging” capability in Subversion. CVS lets you “tag” a label on a file, so you can create a “snapshot” on a repository. If  you use tag to mark the latest production release (and move the tag accordingly) in CVS you’ll miss this functionality. But in my opinion this is just one way to use source control and this shouldn’t be considered a disadvantage in Subversion. In this example, a production release branch can always be created with the release number, which I consider a cleaner way than using a tag. Ultimately everyone has a different way to use a source/version control tool and I think it is a good design point for Subversion to abandon tag. Although I have used “tagging” before in CVS it is not a heart breaker for me to lose it.

There is one thing I do miss is that not being able to hack into local working copy and change repository locations. I used to write a script which search for CVS/Root and CVS/Repository folder and modify the repository name and server/path when I move my CVS repository from one server to another. Now it seems I have to do a fresh checkout in similar situation in Subversion. Which is probably not a bid deal.

All in all I’m pretty happy with the move. My Subversion client is TortoiseSVN, using cygwin ssh to connect to repository through svn+ssh.

During the research I also found Git and plenty of Git vs. Subversion comparison discussion. From what I understand Git facilitates a heavy local work copy so you don’t have to connect to a central repository server, a so-called “distributed source control system”. I can see this feature is extremely useful for projects with a lot of developer and active branches, because the collaborations can happen among the “local copies”.

Any tips on using Subversion? Please share them here. As a new Subversion converter anything will be helpful.