On Sat, May 22, 2010 at 09:42, Mark Phippard <markphip_at_gmail.com> wrote:
> On Sat, May 22, 2010 at 3:18 AM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
>
>> On the TSVN mailing list, a user reported problems when accessing the
>> codeplex repositories with TSVN linked against the svn trunk.
>>
>> Further testing on my side revealed that this problem is due to the fact
>> that serf is now the default DAV lib.
>>
>> When using neon, everything works as expected.
>>
>> For example:
>> svn ls https://mvvmfoundation.svn.codeplex.com/svn
>> with serf leads to:
>>
>> subversion\subversion\svn\list-cmd.c:289: (apr_err=175003)
>> subversion\subversion\libsvn_client\list.c:272: (apr_err=175003)
>> subversion\subversion\libsvn_client\list.c:73: (apr_err=175003)
>> subversion\subversion\libsvn_ra_serf\serf.c:895: (apr_err=175003)
>> subversion\subversion\libsvn_ra_serf\serf.c:833: (apr_err=175003)
>> svn: The PROPFIND response did not include the requested resourcetype value
>>
>> Most other commands don't work either when using serf:
>> svn checkout
>> svn log
>> svn diff
>> ...
>>
>> Using neon works ok.
>
> Aren't they just emulating a Subversion server and the Subversion
> protocol? They have probably just not implemented it correctly.
Exactly.
On baseline collections, the <response> element says it is for
"/!svn/bc/52790/" rather than "/svn/!svn/bc/52790/" (BUG!). Therefore,
the properties get associated with the wrong path, and when ra_serf
attempts to find the <resourcetype> property for path
"/svn/!svn/bc/52790/" it does not find it.
Neon uses a different strategy for determining "is this a directory?",
so a property lookup isn't used, so it doesn't break on this
mis-labeled path.
>...
Does anybody know how to report this bug to the Codeplex people?
Cheers,
-g
Received on 2010-05-24 10:50:06 CEST