Garrett Rooney wrote:
> I'm not sure I like the idea of any and all properties all of a sudden
> becoming things that can be expanded as keywords. It seems like it will
> limit our ability to add new keywords in the future, since it will break
> things for people who already use whatever name we decided on as a
> property for some other use.
I don't really expect anyone (besides me) to load this patch any time soon.
Like I said in my intro, I think this is probably a 2.0.0 feature, so there is
plenty of time to discuss whether/how it gets implemented.
I'm going to use it myself for one and only one purpose: embed the $VERSION in
my Perl modules, so for modules where the XS code (C library) changes but the
POD (doc) doesn't change, I can just increment the version in the properties for
the master file. I have a script sketched out which will be called 'release'
which will do all of the mechanical work of cutting a new CPAN release (so I
don't leave anything out again ;).
>
> Perhaps the user should have to specify explicitly somewhere (in a local
> config file now, server side config file eventually) what properties are
> used as keywords? This would also allow the possibility of specifying
> alternate names for existing keywords (i.e. as the *BSD's use $FreeBSD$
> or $NetBSD$ as alternative spellings for $Id$).
That was one of the original reasons why the original discussion came up.
Unfortunately, it is dependent on server managed configuration files, which
doesn't exist in Subversion at the present time. I agree that it is one of the
more useful extensions that could be done.
>> + /* emit a warning if one has been created */
>> + if (warn)
>> + {
>> + svn_handle_warning (stderr, warn);
>> + }
>
>
> You can't just spew stuff to stderr inside library code. If we need a
> way to handle a warning, you should add a callback function/baton pair,
> so it can be called when warnings occur.
Sorry, I thought that was what I _was_ doing by calling svn_handle_warning().
Care to point me to some code which does the sort of thing you are recommending?
> I'm also not especially thrilled with the 'bail if it has a newline' and
> 'cut it off at some arbitrary size' stuff... I suppose we can't avoid
> the newline thing, but the arbitrary size really bothers me...
The limits are there in the current codebase, check out this code from
subversion/libsvn_subr/subst.c:translate_keyword_subst():
...
/* "$keyword: value $" */
if (vallen > (SVN_KEYWORD_MAX_LEN - 5))
vallen = SVN_KEYWORD_MAX_LEN - 5;
...
so the concept of truncating isn't something I came up with on my own. ;)
I thought in both the newline and size cases, it was better to warn and continue
than to throw an error. When I was testing this patch, I discovered that if I
threw an error for either out-of-bounds conditions, it would cascade up 4 or 5
layers. For example, the code to expand keywords is called in libsvn_wc /after/
the file has been committed to the repository, so throwing an error leaves the
WC in an inconsistent state.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 23 21:08:54 2004