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 > _______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
