Thanks for your patience, everybody, while we've been busy doing other things than fixing this very long-standing bug, which was reported four times and relegated for a long time to a corner labeled "hmmm, what *should* we do with this one, anyway?"
I just wrote and documented a little '/usr/bin/svnwrap' script to set the umask to 002 before executing other svn client binaries. I will include it in next upload (1.3.1-3) in the 'subversion-tools' package. You can see the details in 'man svnwrap', but the short version is, if you do the following: ln -s /usr/bin/svnwrap /usr/local/bin/svn ln -s /usr/bin/svnwrap /usr/local/bin/svnserve that should take care of <file:///> and <svn+ssh://> URLs, and if you use an inetd.conf line that runs '/usr/bin/svnwrap svnserve -i' instead of just '/usr/bin/svnserve -i', that should take care of <svn://> URLs. If you launch svnserve as a daemon (as opposed to inetd) ... well, do the obvious thing. NOTE NOTE NOTE: there's a security implication to doing this with /usr/local/bin/svn (for file:/// access): it affects users' local working copies, not just the repositories. This, by the way, is the reason upstream has never "fixed" this issue properly by just setting the umask inside the subversion binaries themselves. (I can explain further, including why this only affects bdb repos - anyone interested should probably reply privately.) Peter
signature.asc
Description: Digital signature