> -----Original Message-----
> From: Julian Foad [mailto:julian.f...@wandisco.com]
> Sent: dinsdag 6 september 2011 11:24
> To: Markus Schaber
> Cc: dev@subversion.apache.org
> Subject: Re: Inconsistencies in svn_client_info_3
>
> Hi Markus. Thanks for this report, and sorry for the slow response.
>
> There are two different problems here.
>
>
> On Mon, 2011-08-29, Markus Schaber wrote:
> > (This is a slightly enhanced repost.)
> >
> > I'm using latest build of SharpSVN against SVN 1.7.
>
> (To be accurate: you must be using some release candidate or other
> pre-release version of Subversion, as 1.7 is not finalized yet.)
>
> > I'm using SvnClient.Info() which maps to svn_client_info_3().
> >
> > It seems that the svn_client_info_receiver2_t parameter abspath_or_url
> > shows inconsistent behavior when calling svn_client_info_3 on a working
> > copy:
> >
> > When I pass no peg_revision, and set revision to
> > svn_opt_revision_unspecified, then abspath_or_url will be set to the
> > absolute path of the file or directory in question, and
> > svn_client_info2_t->wc_info is set.
> >
> > However, when I set revision to svn_opt_revision_working or
> > svn_opt_revision_base (which both should be local operations as well),
>
> The first problem is a usage problem.
>
> It's maybe not obvious at first sight, but when querying the working
> copy, svn_client_info3() returns all the information about a particular
> WC path, including information about the base version and the working
> version. So specifying 'working' or 'base' explicitly does not actually
> make sense.
>
> The doc string of svn_client_info3() says:
>
> If both revision arguments are either #svn_opt_revision_unspecified
> or @c NULL, then information will be pulled solely from the working
> copy; no network connections will be made.
>
> Otherwise, information will be pulled from a repository.
>
> (Quoting lines from your mail out of order:)
> > Additionally, wc_info is not set, despite "base" and "working" being
> > local revisions.
>
> Because of this rule, when you specify 'base' or 'working', the API
> converts the request into a repository-only request.
>
> What should we do? I suggest it would be better if the API would throw
> an error when you specify 'working'. Being able to specify 'base' to
> request repository info about the base version is a useful behaviour so
> we should keep that. And all of this should be better documented.
>
>
> The Second Problem
>
> > abspath_or_url will contain a relative path.
>
> > Even worse, that relative path is relative to parent of the given path
> > for the directory itself, and relative to the given path for all other
> > entries. (e. G. if you list directory "some/path/foo", then the first
> > entry "some/path/foo" will have "foo" as path, and all others will be
> > relative to "foo", like "some/path/foo/bar" will be displayed as "bar".)
>
> The second problem is that the API is sending a relative path (in the
> ugly way that you describe below) whenever it reports repository-only
> info. I can demonstrate that in the command-line client with a debug
> print in info-cmd.c:print_info():
>
> $ svn st -v C
> 1 1 julianfoad C
> 2 2 julianfoad C/foo
> 1 1 julianfoad C/C2
> 1 1 julianfoad C/C2/baz
>
> $ svn info -R ^/C
> DBG: info-cmd.c: 292: abspath_or_url 'C'
> Path: C
> URL: file:///home/julianfoad/tmp/svn/schaber/repo/C
> [...]
> DBG: info-cmd.c: 292: abspath_or_url 'foo'
> Path: foo
> Name: foo
> URL: file:///home/julianfoad/tmp/svn/schaber/repo/C/foo
> [...]
> DBG: info-cmd.c: 292: abspath_or_url 'C2'
> Path: C2
> URL: file:///home/julianfoad/tmp/svn/schaber/repo/C/C2
> [...]
> DBG: info-cmd.c: 292: abspath_or_url 'C2/baz'
> Path: C2/baz
> Name: baz
> URL: file:///home/julianfoad/tmp/svn/schaber/repo/C/C2/baz
>
> That usage certainly doesn't match the name of the parameter.
>
> I can reproduce exactly the same command-line output with svn 1.6.17 and
> 1.5.9, except that those use both use svn_info_receiver_t in which the
> parameter is called simply 'path'.
>
> It is even more bizarre when you query the root of the repository,
> because then the path returned is the name of the repository (in other
> words, the last component of its root URL):
>
> $ svn16 info -r1 -R
> Path: repo
> URL: file:///home/julianfoad/tmp/svn/schaber/repo
> [...]
>
>
> What should we do here for 1.7?
>
> * Fix the code so that it passes a URL in this 'abspath_or_url'
> parameter for all repository info queries.
I think the best way to resolve this is fixing it to make some sense and move
the strange behavior in the compatibility wrapper.
I found out about this problem some time ago and added a few info_tests to
verify that we didn't accidentally changed this behavior without knowing.
(We didn't test this behavior before 1.7, but it appears we had this strange
behavior for a long time). Feel free to change the tests.
Bert
