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 ?)
On Wed, 2006-11-29 at 15:33 +0100, Marcus Rueckert wrote:
> hi,
>
> as it seems important to you. how about you starting that development
> and commit back a patch to the subversion project?
>
> darix
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 29 23:32:13 2006