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.
>> 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
