Hello once again,
Could I get some design help and feedback from the Subversion people on
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:
> 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: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Dec 5 00:09:34 2006