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

Re: Custom keywords, issue #890

From: Vlad Skvortsov <vss_at_73rus.com>
Date: 2006-09-29 04:26:44 CEST

John Peacock wrote:

> Vlad Skvortsov wrote:
>
>> John Peacock wrote:
>>
>>> Honestly, I think that until a core developer (who may very well be
>>> paid to do so) gets interested in developing the server-side config
>>> piece, I don't see any hope for this to go much farther. That
>>> feature is going to need a champion, and frankly, I'm not up for it...
>>
>>
>> How complex do you expect the changes to be? I'm quite proficient in
>> C but have not hacked any Subversion sources yet. And I would really
>> like to have that feature implemented to put Subversion ahead of
>> competition for *BSD projects.
>
>
> The issue of server-side configuration is more one of design at this
> point. There are several competing ideas, none of which seems to have
> gotten off the ground in terms of serious analysis (other things
> always seem more important).
>
> My initial, back-of-the-envelope design went something like this:
>
> 1) custom keywords would be enabled by setting properties on a file
> (no property set and that keyword is never updated again, which would
> aid in importing sources from other *BSD) - I actually have code to
> make this work already;
>
> 2) inherited properties would ease implementation of this (by setting
> an inherited property at the root of a project it would be set
> automatically for all files underneath it);
>
> 3) initial *client* code would enable certain directory properties to
> be inherited by files in that directory only;
>
> 4) next level of *server* code would handle propagation of directory
> properties down to the next directory (NOTE: this means that checking
> out a leaf node of a large directory tree would require the server to
> recurse up to determine whether any inheritable properties exist
> higher in the tree, which in itself would pretty much require a server
> config setting to enable this at all).
>
> Inherited properties could also be handily used for custom commit
> forms and other useful things. Search the message archives for
> mentions of "iprops" and you should see much of the discussion of this
> scheme.
>
> I believe Brane had a different vision for server distributed
> configuration files for other purposes. He'll have to comment on that...

While I agree that inherited properties seem to be a nice feature to
have, I tend to think that it's quite complex to spec out and implement.
As Greg Hudson pointed out in relevant thread, there is plenty of corner
cases to consider.

Why not storing custom keywords configuration in regular properties? For
large projects (like FreeBSD) migrating to Subversion it would be a
one-time operation to setup appropriate customization. Then, autoprops
and pre-commit hook may be used to ensure consistency.

This leads to another requirement: autoprops should be customizable on
per-repository basis. But it seems to me that it's a much simplier
problem to solve than rolling out iprops or whatever.

Comments?

-- 
Vlad Skvortsov, vss_at_73rus.com, http://vss.73rus.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 29 05:03:43 2006

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.