VCS comparison table

Jakub Narebski jnareb at gmail.com
Sun Oct 22 14:51:54 BST 2006


Matthew D. Fuller wrote:

>   It can also be useful in looking at cases where you don't
>   necessarily have the tool.  Compare putting CVS's rcsid tags in
>   strings in the source.  static const char *rcsid = "$Id"; and the
>   like.  Then you can use 'ident' on the compiled binaries to see the
>   revs of files in them.  If somebody says "foo.c has a bug in 1.34,
>   fixed in 1.37", I can without any VCS interaction just look at the
>   compiled binary and tell whether I'm prior to the bug, have the bug,
>   or after the fix.  If the binary is known to be compiled from a
>   particular branch, a tree-wide revno tells me that too.  A revid
>   (even one containing a date) won't tell me that; I'll have to find
>   the tool and a copy of the tree and find out if my rev contains that
>   other rev.

We use signed tags for tagging official releases (e.g. v1.4.0 tag),
and we use "git describe" output to be embedded during build time
in resulting binary. For example my current output of git-describe
on my clone of git repository is:

 $ git describe 
 v1.4.3.1-g2c8a022

Git project does this, gitweb does this, Linux kernel does this.
This is quite coarse grained, i.e. you know ahich released version
it is after, but you need git tools (or access to git tools via
gitweb) to check if it is after or before the fix.

Of course that is when you run GIT version of tool...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git






More information about the bazaar mailing list