Keyword expansion; Fire and forget keywords

[Martin Pool]

On Mon, May 19, 2008 at 10:20 AM, Markus Mayer <gmane at defx.de> wrote:
> Hi there.
>
> I've seen that Keyword Expansion is on the way. I have an idea
> concerning that, some sort of "fire and forget" keyword.
> When I comment my code I like to track in which version a specific
> function was added or modified.
>
> It would be great to have some sort of $keyword$ that wouldn't get
> expanded, but replaced. (Maybe by not marking it with single dollar
> signs, but with double dollars, so that "$Rev$" gets "$Rev: 15 $" but
> "$$Rev$$" gets "15") This way one could comment everything with skeleton
> comments containing this keyword and would know that upon the next
> commit those keywords get replaced with their correct value - and then
> never again.

Interesting idea.  We have something similar in Bazaar because we mark
new formats with the version that introduced them, and methods with
the version where they became deprecated.  (We don't mark new
supported methods; arguably we should.)

So, first off, you certainly could implement this as a Bazaar plugin,
probably fired from a commit hook rather than content filtering as
such, because you want it to have effect only at commit time.

I am not sure that would really do what you want though.  At least in
our system what's interesting to people later reading the code is in
which _release_ the interface was added, rather than which individual
commit.  So really it needs to be set at the time the change is merged
to mainline.  So we tend to add the expected release number when the
code is created, and then update it when it's finally merged.

-- 
Martin <http://launchpad.net/~mbp/>