> Jay Berkenbilt <firstname.lastname@example.org> writes:
>> A few days ago, the topic of supporting $Header$ came up on the list.
>> While we're on the subject, I'd like to suggestion supporting
>> $Source$ as an alias for $HeadURL$. This would make it possible to
>> use the same keywords for RCS, CVS, and Subversion it at least that
>> additional case.
> There are arguments on both sides, of course, but I think the reason
> we've not made a priority of completely compatible keyword-matching is
> that our keyword values don't correspond to precisely the same
> concepts anyway. For example, the SVN URL and the CVS RCSPath are not
> *quite* the same thing, although they aren't quite different things
Granted. Here's one way in which they are the same: I don't keep
/etc, /sbin, and so forth in subversion or CVS, but I do keep a
parallel tree with only changed files in it. If I put a completely
customized script or configuration file on my system, I rely on
$Source$ (or $URL$) to notify the reader of where the authoritative,
controlled copy of that file actually lives. $Source$ and $URL$ both
provide the functionality with equal effectiveness. Of course, a
simple note in the file header stating that this is a controlled file
combined with a find or locate command would also serve that purpose.
Here's one way in which they differ: $Source$ with CVS gives you an
actual path to an actual file you could look at and do something with;
$HeadURL$ with Subversion does not.
I personally don't feel that strongly about it. Reading arguments
about why keyword expansion is not the default have already made me
change some long-held ideas about keyword expansion. Also, when
creating new files in subversion, since one has to already take an
extra step to enable keyword expansion, they can easily take an extra
step to change $Source$ to $URL$ if they get it wrong the first time.
For my specific case, a 10-line perl script, emacs keyboard macro, and
about 3 minutes were all it took me to make the change in my
Anyway, thanks for considering this request. It will be interesting
to see the outcome. (Sorry for keeping both user@ and dev@ in the CC
-- I subscribe to user but not dev.)
Jay Berkenbilt <email@example.com>
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Feb 7 17:47:14 2005