> -----Original Message-----
> From: David Schweikert [mailto:dws_at_open.ch]
> Sent: maandag 14 november 2011 14:49
> To: dev_at_subversion.apache.org
> Subject: Svnkit incompatibility with Subversion server 1.7 ?
>
> Hi,
>
> We have upgraded our Subversion server to 1.7.1, and since then, one
> application using Svnkit has trouble doing an export of a directory. The
> reason seems to be changed behavior of the "check-path" svnserve
> command.
>
> I did trace what is happening in the SSH session, and with Subversion
> 1.6.12, I see:
>
> server: ( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries
commit-
> revprops depth log-revprops partial-replay ) ) )
>
> client: ( 2 ( edit-pipeline svndiff1 absent-entries depth mergeinfo log-
> revprops ) 62:svn+ssh://user@svnhost/repo/trunk/service/public )
> server: ( success ( ( EXTERNAL ) 36:a0df563e-f38b-6469-9d21-90d8a5590036
)
> )
>
> client: ( EXTERNAL ( 0: ) )
> server: ( success ( ) )
> server: ( success ( 36:a0df563e-f38b-6469-9d21-90d8a5590036
> 33:svn+ssh://user@svnhost/repo ( mergeinfo ) ) )
>
> [...]
>
> client: ( check-path ( 29:/trunk/service/public ( 3155 ) ) )
> server: ( success ( ( ) 0: ) )
> server: ( success ( dir ) )
>
> Note that I did some hand-editing of the paths, so the character counts
> might not be correct.
>
> With Subversion 1.7.1, the server responds the same, except for the
> "check-path" command:
>
> client: ( check-path ( 29:/trunk/service/public ( 3155 ) ) )
> server: ( success ( ( ) 0: ) )
> server: ( success ( none ) )
>
> Interestingly, if the check-path argument is changed to an existing path
> below "/trunk/service/public" (such as "/subdir"), then it works.
>
> In other words: it seems that svnserve 1.7 considers the argument to
> check-path relative to the URL that was used to connect, whereas
> svnserve 1.6 considered it absolute to the repository.
>
> Can you confirm this? Is it a problem in Subversion or Svnkit?
The documentation of this function says that it should be relative to the
session, as all path arguments to ra commands.
This probably worked ok, because we happened to join the path using
svn_path_join() which ignores its first argument when the second argument
starts with a '/'.
In Subversion 1.7 we improved the checking by ensuring that the argument is
a valid relative path (a relpath), which would remove the initial '/', so
then the argument is mapped as a child of the session.
I would call this a bug in SvnKit, as they should have passed valid relative
paths... But maybe somebody else thinks differently about this.
Bert
Received on 2011-11-14 15:26:08 CET