This is the mail archive of the
mailing list for the Cygwin project.
regression in subversion with 1.7.18 (and .19)
- From: David Boyce <david dot s dot boyce at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Mon, 27 May 2013 14:34:05 -0700
- Subject: regression in subversion with 1.7.18 (and .19)
I've encountered a regression in svn client behavior between Cygwin
1.7.17 and 1.7.18. I also tried today's snapshot which doesn't fix it,
though I suspect the problem is actually in the svn port to Cygwin,
not the DLL (by way of evidence I downgraded a 1.7.18 install to use
cygwin1.dll from 1.7.17 and it fails the same way). The problem itself
is hard to explain and maybe to reproduce but fortunately there's some
damning evidence from strace (below) which with luck will make the bug
The symptom involves svn cached password access. Subversion can be
told to cache the user's password in
~/.subversion/auth/svn.simple/<hashed-value> and this is how we use
it. On Cygwin, we point $HOME at the UNC path to our home directories
on a filer and up through Cygwin 1.7.17 (which bundles svn 1.6.16)
this works. Starting with 1.7.18 (svn 1.7.9) it absolutely refuses to
find the cached password via this network path, even if we point to it
explicitly using svn --config-dir=$HOME/.subversion. If we copy the
same path to a local filesystem and point at it with --config-dir, it
works. A really interesting data point is that if we even make a local
*symlink" whose target is the network path and point at that with
--config-dir, it still works. As long as it's a local directory or we
can trick svn into thinking it's a local directory, it works.
Also, the failure is not observed in a fully logged-in Cygwin session.
We see it when using LSF, which is sort of analogous to ssh in the
sense of being a daemon which starts jobs based on network requests.
I'd guess it could be reproduced with ssh but it would take some setup
for me to try that here so I'm hoping the bug can be found without it.
Looking at strace logs is quite illuminating (note that I've scrubbed
these of company identification). Here are the first two lines from a
working (1.7.17) usage:
% grep 'prefix.company.com.*svn.simple' svn.17 | head -2
48 33186 [main] svn 776 normalize_posix_path: src
17 33203 [main] svn 776 normalize_posix_path:
And from the non-working 1.7.18:
% grep 'prefix.company.com.*svn.simple' svn.18 | head -2
22 253378 [main] svn 5848 normalize_posix_path: src
34 253412 [main] svn 5848 normalize_posix_path:
Notice two things:
(1) The double leading // has become a single /.
(2) The working version normalizes the directory whereas the broken
use includes the filename in its path (the full correct path to the
file containing the password is
Taken together it implies an off-by-one error causing a leading
pathname component to be dropped and a corresponding trailing
component to be added.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple