[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: hint for improved keyword substitution

From: John Peacock <john.peacock_at_havurah-software.org>
Date: Thu, 20 Mar 2008 07:09:50 -0400

Mycroft Holmes wrote:
> the most general approach is to have a macro that resolves to an
> _integer_ literal.
> this enables, for example, statements like:
>
> #if SVN_VERSION < 3000

Please do as I suggested and look at the existing Subversion subst.c code and
see if you can suggest something useful. This "meta design" discussion is not
helpful.

These are the design limitations of the current keywords support:

1) All keywords must be delimited by a known [single] character (currently
hardcoded to '$'), in order to be parsed from the character stream;

2) All keywords must be stored unexpanded in the repository (to mark their
location) and will only be expanded in a working copy (or checkout) by the
client code;

3) All expanded keywords must include the keyword as part of the expansion (so
that the WC client code can unexpand them again while performing diff, for example);

4) Expanded keywords cannot span multiple lines.

If you can come up with a backwards compatible extension that would make it
easier to have custom keyword expansions, please feel free to enlighten us.

There is support for enabling custom keywords already in the codebase (by
building up new keywords based on the elements already present). But there
hasn't been an acceptable design to expose that functionality (which comes down
to a lack of server-resident client configuration). See this ticket for some
details:

        http://subversion.tigris.org/issues/show_bug.cgi?id=1974

John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-20 12:09:43 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.