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.
OR
* Change the parameter name (to 'abspath_or_path'?) and document the
strange behaviour.
Can you work around the strange behaviour?
I think in the interest of minimal changes now that 1.7 is in
stabilization, we should do the latter. We can always make another
improved revision of the API later.
- Julian
Received on 2011-09-06 11:25:21 CEST