On Sat, Jul 19, 2008 at 03:49:00PM -0700, Andrew Lentvorski wrote:
a revision control system. Keyword expansion just indicates that the
system either doesn't keep track of file versions very well, or isn't
distributed. If the revision control system is distributed, and everyone
who has the source, has the revision information, then they aren't needed.
Got it in one. Keyword expansion is so that you can work on the file and
know what version it is even when you can't query the revision control
system.
The problem is that if there is any complexity to the code development
process, it just isn't a workable place to put that information. There are
several reasons:
- Lightweight branches. What do I put in the file? Does the revision
control system have to edit every source file just so that I can switch
between branches?
- Changeset. Most systems are moving toward treating a changeset as an
atomic unit. This kind of system doesn't have individual version
numbers for individual files.
- I deliver source to a customer who checks it into their revision
control system. With a distributed system, this could be a branch (and
point 1 is the case), but otherwise, it gets put in their system with
their own version numbering. This header is completely meaningless to
me when they send code back to me.
I like the idea of some kind of version information in the files, but I
don't think keyword expansion is the right thing. In fact, I fairly
aggressively think it is a bad thing to do, to the point where actively
convince people to not only remove it from coding standards and practices,
but forbid it in these same practices.
Also, with a distributed system, even the notion of a 'version' requires
context, and can be different depending on your perspective. Trying to
restrict version numbering to something that can be put in keyword
expansion severely limits what a DVCS can do.
David
--
KPLUG-List@kernel-panic.org
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
