On Fri, Jan 6, 2012 at 8:27 AM, Ivan Zhakov <i...@visualsvn.com> wrote: > On Fri, Jan 6, 2012 at 00:03, Mark Phippard <markp...@gmail.com> wrote: >> On Thu, Jan 5, 2012 at 2:42 PM, Ivan Zhakov <i...@visualsvn.com> wrote: >>> On Wed, Jan 4, 2012 at 02:58, Paul Burba <ptbu...@gmail.com> wrote: >>>> Mike Pilato and I have been kicking around some ideas on server >>>> dictated configuration recently and have put our thoughts into a wiki >>>> (full disclosure: this wiki was initially based on Hyrum's thoughts on >>>> the subject in >>>> https://svn.apache.org/repos/asf/subversion/trunk/notes/repos-dictated-config) >>>> : >>>> >>>> http://wiki.apache.org/subversion/ServerDictatedConfiguration >>>> >>>> We're at a point where it's time to solicit some wider feedback, so >>>> please have a look at the wiki and follow-up here with any concerns, >>>> thoughts, suggestions, etc.. >>>> >>> I think most of use-cases can be solved by existing mechanism without >>> inventing something new: >>> 1. auto-props >>> TortoiseSVN already has 'tsvn:auto-props' property [1]. Which used to >>> automatically set properties for added files. It would be nice if >>> Subversion core support this property. >>> >>> 2. ignores >>> We can add svn:global-ignores property to define global (recursive) ignore >>> mask. >> >> The approach TortoiseSVN and some other clients take does work pretty >> nicely but I also think they reveal the short comings in using >> properties. For convenience, TortoiseSVN does not force you to set >> these properties on every folder and instead will walk to the root of >> your WC to find them, but then this also exposes the problem that if >> you did not checkout the folder that has those properties you are back >> to square one. That is why I believe it makes sense for SVN to >> support it natively using an approach something like described in the >> wiki. Or at least weigh that approach versus using properties within >> the repository. Perhaps properties are the way to add the deferred >> feature of supporting overrides based on path? >> > Well, inherited properties would be nice. And may be we should spend > our efforts to implement them. But even without inherited properties > TSVN solution solves many real world use-cases.
Come to think of it: using properties has the nice advantage that these "configurations" come along when a project is branched or tagged. Which is what most users would expect, I guess. If using some other server-side configuration mechanism, we'll surely have to provide some wildcard support to be able to set a configuration on a certain subtree *and all its branches and tags* (and even then, this isn't the same as taking the configuration with you to a new branch). -- Johan