On Fri, Jan 6, 2012 at 8:27 AM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On Fri, Jan 6, 2012 at 00:03, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Thu, Jan 5, 2012 at 2:42 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>>> On Wed, Jan 4, 2012 at 02:58, Paul Burba <ptburba_at_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
Received on 2012-01-06 13:17:12 CET