Re: [scmbug-users] Re: feature request: server-side config which 'broadcasts' to clients

[Martin Furter <mf...@rola.ch>]

I'm not an svn developer, so these are just a few unreliable thoughts:

How would you edit that config file in the repos root without checking out 
the whole repository? Maybe some checkout -N trickery can help, but I'd 
prefer to have a directory in the repository root which contains that 
file.

Some repositories contain more than one project. How can I make per 
project config ?

In the past server-side config and similar features (f.ex. configurable 
log message templates) have been discussed, and most of the time 
'inherited propertie' have been mentioned, and also discussed. 
Unfortunately those threads always starved (I can't remember why, maybe 
because no consensus has been found).

One of those discussions is here: 
http://svn.haxx.se/dev/archive-2005-06/1121.shtml

Personally I'd like to have server-side config. But I guess inherited 
properties are the best way to implement that, though maybe I'm wrong.
Inherited properties may need a lot of design discussion until everyone is 
happy...

Martin


On Mon, 4 Dec 2006, Kristis Makris wrote:

> Hello once again,
>
> Could I get some design help and feedback from the Subversion people on
> this ?
>
> On Wed, 2006-11-29 at 15:36 -0700, Kristis Makris wrote:
>> I'm willing to try to implement this if a design is agreed upon.
>>
>> One design proposed by Stefan Kueng on Thu Jan 13 09:19:00 -0800 2005
>> described at:
>>
>> http://subversion.tigris.org/issues/show_bug.cgi?id=1974
>>
>> is:
>>
>> Define a file named 'svnrepoconfig' which resides in the repository
>> root. It's treated like a normal file, unless it's
>> 1. located in the repository root
>> 2. has a special new svn property set (e.g. svn:repoconfig = yes)
>> If those are true, then it's not a normal file anymore but one that get's
>> transferred on every update/commit. The client will store it inside the config
>> area, maybe in a subfolder called 'repoconfigs' right beside 'auth' folder.
>> To reduce the data traffic, that file could even be 'versioned' like other
>> working copy files, with the difference that it's stored in the config area.
>>
>> That way,
>> - older clients won't break
>> - the repository root is usually not from where you check out a working copy, so
>> it won't interfere with normal files kept under version control
>> - with mod_authz_svn you can set the access rights so that not everyone can
>> change those settings
>> - you don't need to contact the repository to get the configs - they're stored
>> locally so every client can access them immediately if needed.
>>
>>
>> If this sounds reasonable, then can I assume that Subversion development
>> just *agreed* that this 'server-side config', when implemented, will be
>> implemented as "a file" (e.g. named 'svnrepoconfig') but not propsets
>> (except the special property svn:repoconfig = yes that can be used to
>> indicate a configuration file).
>>
>> ?
>>
>> Also, could someone give me some indication on how I should proceed
>> implementing this (which files do I start looking at ?)
>
> ?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [scmbug-users] Re: feature request: server-side config which 'broadcasts' to clients

[Ben Collins-Sussman <su...@red-bean.com>]

Kristis:  I think it's great that you're so enthusiastic to work on
this feature, but there haven't been any responses from subversion
developers yet.  I think the problem is that the currently active
subversion developers are all working on other difficult things right
now (like merge tracking), and don't have the energy/attention to give
to your design proposal at the moment.

One of the problems here is that we've already had many long,
exhausting discussions about your feature, and haven't ever come to a
consensus on a design.  We've talked about 'inherited properties' as a
way to implement it, as well as other methods.  We're all too tired to
rehash it all again from scratch, which is probably why nobody's
replied to you.  :-)

My recommendation might be to search the dev@ archives for the older
conversations, and see if you can restart the fire based on those
ideas.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org