I just want to put a good word in for the version control program SVK. First a word of warning. This is definitely a programmer’s topic and if you have been reading for the political opinions or entertainment, or even for EP opinions, you should skip this topic.
There, have all the non-programmers left? Ok. Well, if you are a programmer, or want to be one, you should realize that version control is not an option, it is a necessity. This is a fact that no serious programmer is ignorant of. If you are really not familiar with the concept of version control, it is, in a nutshell, the ability to store all previous versions of a file and go back and resurrect any previous version at any time. This allows a tremendous freedom and provides a great sense of security that you are not going to mess something up and not be able to retrace your steps and get back the version you had before you messed up. In other words, it is the ultimate Undo. It is not a matter of whether or not to use version control, but which version control software to use. Recently I became acquainted with SVK, a variation of the Subversion version control system, with a number of advantages over Subversion (aka SVN). SVK represents about my 3rd or 4th foray into version control. For EP Office I used a commercial version control system which was Windows based. As with every other proprietary windows software program, I felt locked into updating the software when updates were released. Of course this cost money, and upgrading is also painful because it invariably breaks something that used to work before just fine. Later I realized the more serious danger of being locked into a proprietary software system: what if the company folded and I was left with unsupported, undocumented software in binary form without source code? What had I entrusted my precious program code to? The situation brought to mind the backup copies I had made using magnetic tape years ago. Those tapes are now useless, as there is no longer any hardware or software available that can read that tape format. Likewise perhaps my carefully archived software would some day be lost because it was stored in a software format that would be be forgotten.
About this time I was switching over to Linux and Open Source software, so naturally I went to the gold standard of version control, CVS. I found that CVS is great for version control of individual files, but is awkward for tracking a large project. I still use CVS for version control on certain text documents, but I don’t think it is very good for development compared to what is now available. If you want to save the state of multiple files all at once, you need to “tag” them with CVS. Deleting and renaming files or directories can also cause major headaches. Moreover CVS does not handle binary files well, and its commands and logic can be obtuse. I still don’t quite understand “sticky tags,” for example.
Enter Subversion (SVN). SVN is directory based, not file based. So if you commit you are committing all the files in a directory, whether they changed or not. The whole directory and its files and subdirectories becomes version 101, for example. You don’t have a mixture of FileA at version 1.2.1.1.4 and FileB at version 1.2.4.1.1, as you might have with CVS. If you delete a file, it just is gone in version 102 onwards, but you can always go back to version 101 to get it back if you want. And SVN handles diffs between binary files just fine. So what’s with SVK that makes it better? In Part II I will examine SVNs shortcomings and why SVK is, in computer geek terms, really neat.
