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