Jay Berkenbilt <email@example.com> 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.
> Just to be extra clear, I'm not suggesting this to ease migration; I'm
> suggesting it to make it possible to use the same set of templates for
> all three revision control systems. There are still going to be some
> places where I will likely to continue to use CVS or RCS for some time
> to come, and $Source$ is the only header from the ones I regularly use
> that isn't supported by Subversion.
> I know others are also interested in this: see issue 980. I would
> have posted an issue, but 980 was closed as invalid, referencing 979
> which was closed as invalid suggesting that feature requests belonged
> on the dev mailing list. But I decided to post here first anyway...
> Please let me know if there would have been a better way to bring this
> up. :-)
Thanks for doing the legwork before bring this up, that helps (I know
our ways of using the issue tracker vs the mailing lists are a bit
unusual, but it makes things easier for us in the long run).
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
Every now and then someone proposes a particular new keyword,
sometimes for compatibility with other systems and sometimes not. We
discuss it, and come to a conclusion in a totally ad hoc way :-), and
I have CC'd the dev@ list now so that the same thing can happen in
My personal opinion? The differences between the two values are great
enough to justify not having a common keyword. However, if the
majority of developers felt differently, I wouldn't try to veto it
either. We'll see if anyone else weighs in. If no one else does, it
just means they don't want to see a change to the status quo either.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Feb 7 03:27:06 2005