On Wed, Aug 14, 2013 at 11:30 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Wed, Aug 14, 2013 at 12:05 PM, Felipe Alvarez
> <felipe.alvarez_at_gmail.com> wrote:
>>> I have the same issue.
>>> It happens when I run 1.8.1 windows client with 1.6.9 https
>>> repository sever. I haven't tried so many combinations ATM,
>>> but here are some observations:
>>> 1.8.1 client run with 1.6.9 https:// repo server gives this issue.
>>> 1.8.1 client run with 1.6.9 generated file:/// repositories are OK.
>>> 1.8.1 client run with 1.7.6 generated file:/// repositories are OK.
>>> 1.7.6 client run with 1.6.9 https:// repo server is OK.
>>> Whether the WC is freshly checked out by 1.8.1 client, or upgraded
>>> from 1.7.6 checked out WC did not change the results.
>>> How's the case for the original poster? Do we see something
>>> in common?
>>> # I'm reading this ML through the archives.
>> Hi Hiroharu
>> You are indeed correct. We have done a very similar experiment here, too. We
>> tried all of the above scenarios you gave. But our older client was 1.6.15,
>> and we did not use https, we used http (apache 2.2)
>> With the help of my colleague we have done some testing with svn 1.8.1
>> (windows 7 and Ubuntu) client and svn 1.6.15 (redhat 5.5) client.
>> Using the file:/// method in all cases works fine (locks NOT broken). All
>> other methods also work fine, including http. Of the tests we made, the one
>> which breaks the locks is: client 1.8.1; repository made with svn 1.6.15;
>> protocol HTTP (apache 2.2).
>> One method that we have not yet tried is: client 1.8.1; repo with svn client
>> 1.8.1; protocol HTTP
>> How do I enabled debugging in .subversion/config or .subversion/servers? It
>> used to be something like "neon-debug" but that's no longer available since
>> 1.8.1 (or 1.8)
> As of 1.8 SVN only uses the serf library for http communication, and
> no longer the neon library (before 1.8, both were part of svn, but
> neon was the default library).
> Unfortunately there is no runtime-switch (yet) to enable debug output
> with svn+serf. There is already an open enhancement request for this
> You can enable debug logging with serf by rebuilding (see ).
A FYI to Johan: note that there are two levels of abstraction here:
- serf: the http library that's now used instead of neon: implements
the http protocol and sends/receives bytes over the network
- ra_serf: the subversion ra module that uses serf to communicate with
a mod_dav_svn module in an apache server via XML request/reply
If there's an issue that looks like missing or corrupted data,
connection or authentication problems then we look to the serf
library. The logging you refer to is then a good way to start
gathering info on what's going wrong.
However in this case it seems that the communication itself is ok, but
there's a potential issue in how ra_serf drives the communication
(i.e. the content of the xml requests). Serf logging will not help
here as it's a level too deep. A simple wireshark trace can help, once
the exact reproduction recipe is known.
(serf can also log request and reply output, even with https, but it's
easier to use wireshark)
> With your combined input, this issue really starts to look like a
> serf-related issue.
> - Succeeds with file://
> - Fails with http(s), but only with 1.8 clients, not with older clients.
> To double check that it's serf-related, perhaps one of you could try
> with 1.7+serf, and see if that fails as well. You can enable serf with
> 1.7 by specifying http-library=serf in the servers configuration file,
> or by passing
> --config-option servers:global:http-library=serf
> on the command line.
> Perhaps it's time to open an issue in the issue tracker for this.
>  http://subversion.tigris.org/issues/show_bug.cgi?id=4407 (Provide
> serf equivalent of neon-debug-mask)
>  http://svn.haxx.se/users/archive-2013-07/0344.shtml
Received on 2013-08-15 10:31:49 CEST