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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html