On Mon, 10 Oct 2005, John Belmonte wrote:
>
>
> Peter N. Lundblad wrote:
> > On Mon, 9 Oct 2005 kfogel@collab.net wrote:
> >
> >
> >>John Belmonte <john@neggie.net> writes:
> >>
> >>>>I expect "svn info <URL>" to have a non-zero rcode if the URL is not
> >>>>valid. Seen in version 1.2.3. May I file a bug?
> >>>>
> >>>> $ svn info http://svn.collab.net/repos/svn/bad_url
> >>>> http://svn.collab.net/repos/svn/bad_url: (Not a valid URL)
> >>>> $ echo $?
> >>>> 0
> >>>
> > The problem with the return code is that these are handled like warnings,
> > a message is printed and we continue with the next target (but the output
> > is not preceded by svn: warning: as it should). So we can't return a
> > failure status in this case.
>
> Are you saying that you can't correct the return code problem? Surely
It can be made a fatal error instead of a warning. My point was that if it
is not fatal and the client continues with the next target, we can't
return failure because the next target might succeed.
> it's arbitrary (from the point of view of the client) that the case
> above succeeds while the following fails. Any bad URL should fail.
>
> $ svn info http://svn.collab.net/repos/svn_bad
> svn: PROPFIND request failed on '/repos/svn_bad'
> svn: PROPFIND of '/repos/svn_bad': 405 Method Not Allowed
> (http://svn.collab.net)
> $ echo $?
> 1
>
It's not completely arbitrary, since giving an URL that doesn't point to a
repository is fatal, but giving an URL with a non-existent path *inside*
the repository is not. We (inconsistently) treat errors like "not under
version control" and "file does not exist" as non-fatal so you can use
wildcards. When thinking about this, it only seems to make sense for
working copy targets, though. So we could get rid of this for URLs if we
wanted to.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 10 15:00:51 2005