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.
>>> --
>>> Hiroharu
>>
>>
>> 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
> [1].
>
> You can enable debug logging with serf by rebuilding (see [2]).
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
messaging
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)
Lieven
> 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.
>
> [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4407 (Provide
> serf equivalent of neon-debug-mask)
>
> [2] http://svn.haxx.se/users/archive-2013-07/0344.shtml
>
> --
> Johan
Received on 2013-08-15 10:31:49 CEST