Peter Pentchev wrote:
>>> Oh, you mean something like that, right? :)
>>> As a matter of fact, I've updated this patch for 1.4.0, it's up at
>>> And yes, I know that this is not really a good approach, and that each
>>> client binary wants to be patched (not "needs", since nothing will
>>> break, just the keywords won't be expanded), but still - it does what
>>> I need right now for my personal repository, until a better solution
>>> comes along.
>> Hey, I really like the approach! While it's not as generalized as
>> 'custom keywords', it's much simplier and seems to solve the current
>> What is the status of the patch? Is that handed off to the patch manager?
>> If my vote would count, I'd say +1 on that. :-)
> Well, I'd suppose the patch has the same status as it had back in February
> when I first suggested something like this - an unofficial, unapproved
> patch that does the job for me, and that will probably not make it into
> Subversion itself for many reasons (and, just for the record, I do agree
> with those reasons).
> The main reason was, actually, mentioned in this thread - this is only
> a per-file setting, and thus has to be propset'd for each and every file
> in the source tree. Either repository-level options or inherited properties
> would be a much, much better approach - thus, this is only a temporary
The 'svn:keywords' property needs to be set on per-file basis too and it
doesn't seem to be a showstopper. As was previously discussed in this
thread, ability to automatically set properties (as iprops, repository,
or client-side settings) may be implemented as an orthogonal feature.
Having custom (or alias) keywords without that may still benefit
Subversion in many ways.
> Still, I'm glad to know that you like it :)
Vlad Skvortsov, vss_at_73rus.com, http://vss.73rus.com
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 19:36:37 2006