On 7/28/05, Morbus Iff <morbus@disobey.com> wrote:
While I think it's a good idea, I'm not sure:
* discovery of the CVS $Id$ tags of every .module, .inc, .theme, .css .xtmpl, etc. storing of these version numbers
this is a good way to implement. Somewhere in the CVS docs, they caution AGAINST using $Id$ as a version number. Off the top of my head, I can think of some reasons why:
* CVS server crashes, wiping out all histories. Revisions start over.
* Just because I patch my local copy doesn't mean I committed my patch to a server somewhere, or that I changed the $Id$ of my local copy. Comparisions would fail.
* $Id$ isn't everywhere, is it? Does it always lock us into CVS forever, or are there easy equivalents in SVN? And, if we did switch to another RCS in the future, what happens to all the $Id$s we've been basing comparisons on?
Excellent points, all, but is there a solution that is simple, elegant, and right? Patching your version isn't addressed by the discovery and storage of $Id$ tags, but if the MD5 hashes could be used, we would know, for instance, that even though your search.module says it's version 1.130, the hashes don't match. (it could even run a diff, would't *that* be helpful for support) $Id$ might not be everywhere, but at least SVN has a similar construct. So, if $Id$ isn't ideal (and I'll concede that point), are hashes the answer? something else? I'm completely open to all ideas here. I'm convinced there's a need for some sort of standardized method of providing release version information, and I'd love to see that, umm, hashed out. :) -- e one inch frame: http://eafarris.al.umces.edu/