Re: Custom Keywords (1.1-consider )

Greg Hudson wrote:
> On Tue, 2004-06-15 at 23:12, John Peacock wrote:
>
>>>It seems like your patch does more than this; it adds an (undocumented)
>>>props parameter to svn_subst_build_keywords2,
>
> It needs to be in the doc string for svn_subst_build_keywords2, not just
> "somewhere."

Point made; I'll add that in the next revision.

>>Well, duh, that was the point of the exercise after all. ;)
>
>
> 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?

>
> I don't understand the vision here. You seemed to be moving in the
> direction of simply allowing the user to put "propname" into
> svn:keywords, and have "$propname$" expand to "$propname: propval$". I
> don't see where the formatting comes in.

That's *one* thing that I considered, since we don't currently have a way of
handling site-specific keywords yet. Ideally, we would have a file
conf/keywords.conf with something like the following:

[keywords]
FreeBSD=%b %D %a %r

and then a mechanism by which the client (which has to do the expansion) can
query the server for this information. This is part and parcel of the whole
repository-wide defaults issue.

But, the two patches I provided are only the necessary framework. Hardcoded
typedefs are not extensible and simply replacing a typedef with a hash and
continue hardcoding the format strings seems to be an unnecessary baby step,
since plasma already provided all of the printf-like behavior in his original patch.

>>I have hope that there will eventually be inheritable properties
>
>
> The feature seems only barely useful without inheritable properties, in
> fact ("svn propset" is more scriptable than a file edit, but that's
> it). Inheritable properties are a nifty idea, but they're a huge can of
> worms, so I'm reluctant to introduce features which aren't useful in
> their absence.

I agree that inheritance is a bitch, but we need to deal with it for ACL's as
well, so a generic methodology to walk the tree and find the current applicable
attribute (whether that is ACL or properties) is very likely to be available in
the future. I'm not holding out for any of that prior to 2.0 (based on what
Brane has suggested he is planning on).

However, *I* could use this feature (specifically with the property-as-keyword)
right now. Since a normal Perl module (as released on CPAN) has a single file
as the source of the package version, I only need to set a single property.

> If we do this, I think the right answer is to (a) eliminate the
> SVN_KEYWORD_MAX_LEN restriction, and (b) just silently truncate at the
> first newline.
>

That would probably take me 10 minutes to implement, so I am all in favor of
that... ;)

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org