All Things Patrick - Working Hard to be Lazy!

At work I'm currently stuck using CVS... I think we're planning to make the move to Subversion (SVN), but I'm not sure when. I've used CVS in the past, but I didn't know a whole lot about what I was doing and most of what I was doing was via a GUI on windows. I knew what CVS was doing with the diffs it was taking because I had messed around with RCS and looked at the version files RCS creates - CVS started out as a bunch of shell scripts for RCS. Beyond the basics of checkout and commit I'm really not all that familiar with CVS anymore. All I ever really did was either utilized a local repository or somebody else provided me with a checkout command for either a kserver or a pserver. I still have no idea what the difference is between a kserver or a pserver.

After I got started with SVN it seemed like all the esoteric wizardly commands disappeared. SVN seems to have a lot of sane aliases for various commands making them easier to remember. Let's take the delete command for example. On Unix to delete a file you use rm (ReMove) and on DOS/Windows you use del (short for delete), both CVS and SVN have multiple aliases, but it's not as obvious for CVS - you'll have to go digging pretty far through the man page to find them. Here's CVS help:

$ cvs help
Unknown command: `help'


CVS commands are:
        add          Add a new file/directory to the repository
        admin        Administration front end for rcs
        annotate     Show last revision where each line was modified
        checkout     Checkout sources for editing
        commit       Check files into the repository
        diff         Show differences between revisions
        edit         Get ready to edit a watched file
        editors      See who is editing a watched file
        export       Export sources from CVS, similar to checkout
        history      Show repository access history
        import       Import sources into CVS, using vendor branches
        init         Create a CVS repository if it doesn't exist
        log          Print out history information for files
        login        Prompt for password for authenticating server
        logout       Removes entry in .cvspass for remote repository
        pserver      Password server mode
        rannotate    Show last revision where each line of module was modified
        rdiff        Create 'patch' format diffs between releases
        release      Indicate that a Module is no longer in use

        remove       Remove an entry from the repository

        rlog         Print out history information for a module
        rtag         Add a symbolic tag to a module
        server       Server mode
        status       Display status information on checked out files
        tag          Add a symbolic tag to checked out version of files
        unedit       Undo an edit command
        update       Bring work tree in sync with repository
        version      Show current CVS version(s)
        watch        Set watches
        watchers     See who is watching a file
(Specify the --help option for a list of other help options)

Ok, nifty, but most new people are looking for a way to delete a file. Not only that, but CVS complains that help is not a known command, but --help doesn't give anywhere near the same information :( Ok, so now let's look at SVN:

$ svn help
usage: svn <subcommand> [options] [args]
Subversion command-line client, version 1.4.6.
Type 'svn help <subcommand>' for help on a specific subcommand.
Type 'svn --version' to see the program version and RA modules
  or 'svn --version --quiet' to see just the version number.


Most subcommands take file and/or directory arguments, recursing
on the directories.  If no arguments are supplied to such a
command, it recurses on the current directory (inclusive) by default.


Available subcommands:
   add
   blame (praise, annotate, ann)
   cat
   checkout (co)
   cleanup
   commit (ci)
   copy (cp)

   delete (del, remove, rm)

   diff (di)
   export
   help (?, h)
   import
   info
   list (ls)
   lock
   log
   merge
   mkdir
   move (mv, rename, ren)
   propdel (pdel, pd)
   propedit (pedit, pe)
   propget (pget, pg)
   proplist (plist, pl)
   propset (pset, ps)
   resolved
   revert
   status (stat, st)
   switch (sw)
   unlock
   update (up)


Subversion is a tool for version control.
For additional information, see http://subversion.tigris.org/

If we're new to SVN (or Unix) or we're simply discussing what we want to do in general english, we're trying to delete a file and there it is... easy to find under delete. Not only that, but it also lists all of it's aliases, so those of us used to using rm in Unix know we can use something similar without trolling through pages of documentation.

The other fun one is that for both CVS & SVN you checkout a working copy and after you've made changes you need to post those changes back to the repository. Now, if you've checked them out, wouldn't you check them back in? You know, checkout ~ checkin ? Well, that's true in SVN, but in CVS you commit your changes. Sometimes I want to commit people that still like CVS :)

My next peeve with CVS is the status mechanism. Maybe it's just that I've gotten used to the way SVN does it, but I tried to get a status on the directory I was in and my screen got flooded with information on all of the files in the current directory. How the hell do I get a status report similar to SVNs? Here's a very, very short list of status output from CVS:

$ cvs st | head -n 27
cvs status: Examining .
cvs status: Examining dbconf
===================================================================
File: db.conf           Status: Up-to-date


   Working revision:    1.1.1.1 Mon Jun 16 14:35:35 2008
   Repository revision: 1.1.1.1 /usr/local/cvs/ddo2go/dbconf/db.conf,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)


cvs status: Examining ddodocs
===================================================================
File: ddo_tech_specs.doc        Status: Up-to-date


   Working revision:    1.1     Tue Jun 17 13:59:17 2008
   Repository revision: 1.1     /usr/local/cvs/ddo2go/ddodocs/ddo_tech_specs.doc,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)


cvs status: Examining ddodocs/dbschema
===================================================================
File: ddo_data.xls      Status: Up-to-date


   Working revision:    1.1     Tue Jun 17 13:59:17 2008
   Repository revision: 1.1     /usr/local/cvs/ddo2go/ddodocs/dbschema/ddo_data.xls,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

Ok, well that's really nifty (notice I used head to show only the first 27 lines - I didn't want to torture you with the entire thing), but what I really want is a listing of files that have disappeared, modified, added, or deleted. I really don't care about files that haven't been touched. Let's see what the status output looks like from SVN:

$ svn st
?      install.txt
M      www/index.php
A      readme.txt

The ? means that the file has not been added to the SVN repository yet. M means the file has been modified, A means the file has been added, and D means the file has been deleted. Very quick and easy to read. Plus I don't have to troll through a huge status listing or grep through it to find changes. Granted, grepping the listing isn't hard once you know what you're looking for:

$ cvs st 2>&1 | grep Status | egrep -v 'cvs status:|Status: Up-to-date'

but that just gets annoying. To get a shorter 1 liner for each file you can simply do a cvs up, but that pulls changes from the cvs server and can end up causing you to have conflicts prior to wanting to deal with them... i.e. I'm still in the process of adding files and having a conflict is going to cause me to stop what I'm doing, deal with the conflict, & then try to remember what it was I was trying to do before the interruption.

We've also having problems with people committing their work, leaving a note, and then CVS seems to commit everything just fine, but then the repository ends up being locked. The problem happens to be with using vi as the editor and not specifically with CVS - the issue was that the person was sending vi to the background rather than saving the file. However, your repository should not be dependent upon somebody trying to type in notes about what they changed. SVN doesn't have this problem as far as I know... it only connects to the server after you're done entering your notes and then it checks to match the repository version on the server against what you're trying to checkin. If there's a difference SVN makes you run an update before checkin - CVS on the other hand doesn't complain about any problems until it gets halfway through making a commit, then realizes there's a problem, and blows chunks... Unless of course somebody else is currently in the middle of making notes - in which case it complains that the entire repository is locked and won't even let you check out a working copy (or at least with CVSNT).

Something that our lead developer has gone on about why he likes CVS is he can use his kserver or pserver - as I mentioned before I have no idea what these do. My guess is that these are built in protocols within CVS. I don't know whether these means that CVS runs as a server daemon or not. I do know that Subversion will work over ssh, http, and https - I've heard about webdav, but I'm guessing that's the same or similar to http. On my personal servers I use SVN over ssh, most of the places I've worked that use SVN have it set up over https. The only place I've seen http used is read only on a lot of open source projects, but please note that these are set up as read only - the http protocol doesn't handle encryption.

The reason I use ssh is that I'm lazy and like utilizing ssh keys. Further information regarding ssh keys is beyond the scope of this posting and can easily be found via google.

Another issue I'm having is beyond the scope of CVS vs SVN, but might be useful for anybody looking at this that haven't thought about this. The CVS repository is currently on the development server. The only place we're supposed to check code out is on the development server. Granted, I think the CVS repository is backed up on a nightly basis, but... What happens if the development server loses it's hard drive? There goes an entire days worth of work - even if the server goes down at 9am... Because it means nobody has a local copy that they can work on and mess with until the server is back up.

Put your repository on 1 computer and check out your code to a 2nd computer. This way if Bob’s desktop has a hardware failure he can at least grab another computer and get some work done even if he doesn't have his preferred work environment. If the repository server has a hardware failure (and you have backups) you've not lost much of the repository, Bob can continue working (only he can't commit anything until the repository server is back up). Unfortunately if the repository server goes down, you still have to figure out what's changed. This should simply entail rsync'ing the working copy (A) to a new location (B) and reverting it. Then checkout the restored project to a 3rd location (C), rsync copy B over copy C (with --exclude=.svn), and commit C with a note stating you're updating code changes that were made while the server was crashed. Then rsync copy A over copy C (again with --exclude=.svn) and that's your new working copy - A & B can be deleted. I'm not sure whether other developers can simply run an update or if they will then need to check out the restored project and rsync (using --exclude=.svn) over the new checked out version in order to be up to speed... But this is worste case scenario.

If you're really worried about single point of failure issues or allowing a developer to work remotely during a period of time where they may have no or limited network access then a distributed version control system would be even better than SVN. The linux kernel has moved to using GIT and a lot of developers on other projects are appreciating it as well. With GIT, each developer has their own local repository that they can work from and commit to. You can still use a centralized server model, but all this entails is a server that all the developers regularly sync their local repositories with. In order for this to work well GIT has a very fast merge computation. It may require a bit more human intervention in some merge cases, but it does mean that if the central server has a hardware failure developers can continue work with no problems. They keep checking in to their local repository and if they need to sync with other developers they can have their local repositories sync and deal with the central server later. This also means if someone is unable to get on the companies VPN from home, they can still either sync with another developer who can connect to the VPN, or they can sync their home repository while they're in the office.

Yet another small annoyance outside of CVS vs SVN with the fact that we all have our own development space on the development server. Rather than having our own vhosts we're all developing from /~username/project/ so utilizing mod_rewrite within a .htaccess can cause problems when RewriteBase is required and you're trying to check it in to CVS. Either A) each developer needs to remember that they have to change the .htaccess for their directory scheme or B) I need to write a bash script that will auto generate the .htaccess file, make sure CVS ignores the .htaccess file, and make sure that each developer realizes they need to run `bash generate-htaccess.sh` (including on the production server) - and yes, using bash is required because CVS doesn't keep track of the executable bit. Is there a C option?