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