Comments in pickles?

Tim Peters tim.one at comcast.net
Wed Jul 3 00:07:01 EDT 2002


[Roy Smith]
>>> Our usual practice is to imbed the CVS id string ($Id: ) in every
>>> checked-in file as a comment.

[Tim]
>> I encourage you to question that practice.

[Roy]
> This is getting a little off-topic, but why do you say that?  It's the
> most convenient way I know of to identify a file when you're looking at
> it.

I would have thought the name of the file would be far more helpful <wink>.

If it isn't, what does a number like 1.18.16.3 tell you that's of such
compelling use you can't afford to do a "cvs stat" to get it?  All it tells
me is that I'm working on a branch, but if I'm working on a branch I already
know that.  I rarely care about who last checked the file in, or when, but
those are easily obtainable too.

BTW, bogus conflicts on embedded RCS Ids are going to drive you mad if you
ever do significant work with branches -- they impose large artificial costs
then.  Before then, they're just geek fluff.

Code that tries to be so clever as to *extract* pieces of embedded RCS ids
for display, or to check its own version, is also notorious for breaking
(producing gibberish in Python code, segfaults in C code).  Indeed, Guido
once cut a badly broken release of Python by "innovating" in how he checked
out the source tree, breaking the few bits of clever code that try to parse
embedded RCS ids in Python's source base.  We purged almost all of that code
then.

Another problem, perhaps peculiar to open source projects, is that when a
file from another code base gets checked in, the $Id expansions instantly
differ radically, and people who have been lulled into trusting these
expansions have been known to waste hours trying to find non-existent
differences before the light dawns.

In short, an embedded $Id never did me any good, but has wasted my time and
tempted people to write code with severe bugs.  If you just leave the $Id as
a passive piece of a comment, I suppose the real damage is limited to making
merges artificially painful.

otoh-if-you-love-'em-go-for-it-ly y'rs  - tim






More information about the Python-list mailing list