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

Re: Custom Keywords (1.1-consider )

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-06-18 03:42:41 CEST

On Wed, 2004-06-16 at 07:48, John Peacock wrote:
> > I thought the point of the exercise was to replace the keyword structure
> > with a hash.
>
> But replace it with a hash of hardcoded format strings or something that is
> ultimately much more useful?

What I want to avoid is the code getting into a halfway state, where we
have machinery for a feature we never wind up coding.

Replacing the keyword structure with a hash, and doing nothing else,
seems like a nice way of making the keyword mechanism more generic--or
it would, except that the API of svn_subst_build_keywords seems
dependent on what kind of information goes into keyword processing.

Adding a printf framework, on the other hand, is just a waste of code if
we never wind up adding a feature that would let us do FreeBSD --> "%b
%D %a %r" or whatever. So, in the absence of a spec and design for such
a feature, I don't want to see the printf framework code going into our
tree.

Also, a note on properties-as-keywords: the patch you sent to the list
(http://www.contactor.se/~dast/svn/archive-2004-04/1184.shtml) does not
appear to re-substitute files after an "svn propset". Without that
code, the working copy can easily get into an inconsistent state, and I
don't think that's acceptable. (Of course, any code to re-substitute
files after propset would have to be careful not to impose a great cost
on propset operations for files which have no property keywords.)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 18 03:43:32 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.