half of an adder

Recently, there seems to be a proliferation of revision control systems. In the django community, many started out using google code, which offers subversion, but now many projects are found in git or mercurial repositories.

Knowing the revision number is helpful in giving unique names to checked-out versions of django applications. And here's how to do that in various systems.

With subversion it's easiest to just get the revision number from the output of checkout. For example, if we want to check out dregni:

Alternatively, the info command will output the revision number:

With mercurial, the latest revision can be found with the identify command.

The revision number can be used to uniquely identify the version of the checked-out application. Note that this is only true if we're pulling from a centralized repository! Revision numbers can differ between developers (that's why there's a hash after the revision number), so if you're pulling from an independent developer you should use the entire changeset number.

Finding the revision in git is pretty much the same as in mercurial:

There's no helpful tiny revision number, however, so we have to use the entire commit hash instead.

But what about CVS, you say? Well, while CVS has a concept of revision numbers, these apply only to individual files and not to the entire source tree. If you do a cvs checkout you'll get the highest available version of each file (__init__.py might be version 1.1 at the same time models.py is version 1.8). As a result, if you're checking out from HEAD, the most unique version information you have is the datetime. date can print the datetime in a CVS-compatible format:

But this doesn't work so well for directory naming. Using something like %F-%H.%M.%S-%Z might be better.

Alternatively, if the CVS repository has a useful tag which can be checked out with cvs checkout -r tagname, then this can be used in the same way as a revision number from subversion, etc.