[ sorry Robby, I left you out of a previous reply -- looping you back in in case you're interested in this tangent ... ]
On Tue, Aug 24, 2021 at 10:34 AM Stefan Sperling <s...@elego.de> wrote: > > On Mon, Aug 23, 2021 at 02:45:44PM +0200, Johan Corveleyn wrote: > > Thanks, those are good efforts (and thanks to both Daniels for writing > > them), but I'm afraid those workarounds are not good enough. The thing > > is: this is not for me alone. This needs to be handled in buildscripts > > that can be run by around 50 developers. > > One thing is unclear to me: > > At some point, someone has to run an svn command to get the passward > cached on Solaris in the first place or build scripts would be failing. > > How is this done? Each of the 50 developers ran 'svn checkout' or > something similar to get the password cached? Or does the password > get cached in a non-interactive, automated way? > > The point of this question is to understand whether my 'svn auth add' > proposal described elsewhere in this thread would solve your problem. These buildscripts are run manually / interactively on this machine (developers take turns for this weekly task, for different applications). For most applications there is a canonical (shared) working copy on this build-server, so they reuse that (or otherwise they can set one up quickly with a script). The buildscripts are written in ant (we're building Java applications actually). The ant targets that do something with svn have a "depends=svn-checkpwd" clause, which makes them first call the "svn-checkpwd" target. This does a minimal password-requiring thing with svn (I think it is something like 'svn ls https://svnserver/repo >/dev/null'). If the cached password is still correct, user sees nothing (carry on), if not they get a password prompt and type in the new password. I suppose I could rewrite that 'svn-checkpwd' target to use 'svn auth add' or something similar, but I should also have a way to verify whether the cached password is still valid (so I can get the same behaviour as before: only bother the user if the cached password is no longer valid). But: obviously I have disabled, in the runtime config area, the warning prompt that "Your password will be stored in plaintext" (I have disabled it system-wide, in /etc/subversion). Yes, we know this and we accept it. I would not like this nag screen to be forced with no way for an admin to disable it. Ah, I might be able to write a wrapper script to dev/null the warning :-). All this effort for ... nothing (from my perspective). Perhaps a meta-itch here: the old behaviour has been there for 20 years, and then we decided to change this. In the super-stable-mature-super-backwards-compatible part of our lifecycle. Not the best timing I think. Perhaps this should have rather been on the 2.0-wishlist ("Come up with a better pwd caching solution on non-Windows platforms"). -- Johan
