Am Fri, 7 Aug 2020 05:53:24 +0000 schrieb Daniel Shahaf <d...@daniel.shahaf.name>:
> > > should work: the compile-time knob prevents passwords from being > > > _written_, but doesn't prevent passwords already there from being > > > read. Then it might be a nice idea to allow users to intentionally trigger that write when they know what they are doing. Well, that was of course what the old behaviour did, but a bit implicitly. Once could imagine a new command to make it explicit. Something like svn store-password $user $repo . But I suspect subversion devs don't fancy adding extra cruft to support the use-cases for passwordless operation. I'm not sure what games one could play with client certificates or similar. Storing the password is for sure a lot simpler and doesn't need setting up svnserve with SASL (although I did that for encryption). Building it myself is not that hard. So I have my script that installs svn with plaintext password storage and I use that as part of bootstrapping our systems. I'm preparing my little add-on rant as reply to the initial post to give some more colour. Short version, in case I don't make it: Disabling plaintext passwords makes it harder to keep using Subversion in cases where it is truly superior to DVCS. For code development it's hard to justify Subversion nowadays, when there's not even a standard property to differentiate between author and committer of a patch (I guess one could just define one by convention?). I keep using it for existing projects but feel increasingly stupid for doing so, despite my opinion of the file tree semantics being superior to branching/tagging elsewhere. Alrighty then, Thomas -- Dr. Thomas Orgis HPC @ Universität Hamburg