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

Re: suggestion for more custom keyword options (Issue 890)

From: John Peacock <jpeacock_at_rowman.com>
Date: 2004-12-30 12:59:02 CET

John Belmonte wrote:
> I didn't think that the new format options necessarily warranted new
> builtin keywords-- having them available only to custom keywords would
> be enough for me. Your revised format characters look fine.

Except that I haven't worked on a way to expose custom keywords yet, so without
builtin keywords, you cannot use them. I'm of the opinion that if these
keywords are useful enough to add at all, they are useful enough to warrant new
builtin's for them. The custom keyword functionality has always been about
reusing the existing keywords in new and interesting ways.

If I get the proposed $Format$ keyword working, then this would be an ideal way
to expose the custom keyword functionality. I don't know how likely it is going
to be to do that; the issue is that I don't have the usual markers for expanded
vs unexpanded keyword to work with and I'll have to be very careful about how I
proceed. I may have to have $Format$ and $/Format$ markers...hmmm, that would
also work for those poor lost souls who want to have $Log$ working...

> From my limited understanding, the repository root is available from
> the RA interface (get_repos_root). By subtracting the root from the
> URL, you can get the repository-local path.

And therein lies the rub: I don't have access to the session_baton (required to
call get_repos_root) at that point in the code. The keyword processing is all
performed in the parts of the code dealing specifically with the working copy.
In fact, the keyword expansion itself happens _after_ the commit/update has
completed and hence the session_baton may not even be in scope at the time. It
may be that the svn_wc_entry_t would have to be extended to contain the
repos_root (and populated earlier in the process), so that I can retrieve it
later. :(

John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 30 13:01:07 2004

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.