[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] Server Dictated Configuration

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Fri, 6 Jan 2012 11:27:59 +0400

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.

>> 3. store-plaintext-passwords
>> Since most used of platforms already supports password encryption
>> (Windows, MacOS, KDE, GNOME) I think we can safely just change to do
>> not store plaintext by default.
> You must not spend time working with Unix users.
That's true: I live in wonderful Windows where Group Policy could
serve everything :)

> The options we
> provided are good, but do not seem to be enough and there is no way to
> enforce policies where they have to be used.  It also does nothing to
> help things like automated build processes and scripts that need to
> run on Unix and cannot interact with a keyring.
> I do not pretend to have an answer though.  Making plain text off by
> default might be a start.
I don't pretend that my proposal solves all problems, but I think they
should notably improve situation for users.

Ivan Zhakov
Received on 2012-01-06 08:29:25 CET

This is an archived mail posted to the Subversion Dev mailing list.