Hi, Julian,
Von: Julian Foad [mailto:julian.foad_at_wandisco.com]
> Hi Markus. Thanks for this report, and sorry for the slow response.
Thanks for answering, nowadays its holidays time. :-)
> 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.)
Yes, it is the latest build from http://sharpsvn.open.collab.net/daily/1.7.x.
As it is not finally yet, right now is the best time to find and report bugs. :-)
> > 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.
Ah, ok. So this was my problem in thinking - I passed "working" to get information about the working copy. :-)
> 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.
Maybe throwing an error is a good idea, and the documentation should be better.
Or implicitly treat "working" as "unspecified".
Interpreting "working" as pulling information from the repository seems a little bit weird, at least for my very own brain.
> 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?
Yes, simply passing "None" as the revision works fine for us, as we currently do not need remote information. That’s why I specified "working" first, in blind ignorance of the SVN doku, seeing only the SharpSVN api :-(
Constructing a usable path from the abspath_or_url for remote access seems to require somewhat fragile heuristics in my client code, so maybe the problem will reappear someday when we need remote info.
> 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.
My wish would be that we get both an abspath and an url if the item is both in the working copy and in the repository, and one of them in the other case. The "abspath_or_path" is rather unusable as it is now for remote queries - if at least it was relative to the same root in all cases, we could use it.
But I agree that the fix needed maybe too fragile for 1.7, so let's hope that 1.8 will have a shorter release cycle. :-)
Best regards
Markus Schaber
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Received on 2011-09-06 12:17:15 CEST