On Sat, May 22, 2010 at 09:42, Mark Phippard <markp...@gmail.com> wrote: > On Sat, May 22, 2010 at 3:18 AM, Stefan Küng <tortoise...@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
