On Wed, 12 Oct 2005, Julian Foad wrote:
>
> > 2) I disagree that an invalid URL "inside" a repository is only a
> > warning. As I've said, this is arbitrary from the point of view of the
> > client. If I'm scripting and all I have is the command line client and
> > a given URL, how do I determine if that URL is valid or not? In the
> > past I've used "svn ls", but "svn info" should be usable here to. If ls
> > returns an error for a URL, shouldn't info do the same? They both
> > return data about a file on directory node.
>
> Yes, I completely agree with you. I was going to reply to Peter about that:
>
> Peter N. Lundblad wrote:
> >> 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.
> >
> > 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.
>
> The only sense in which it is "fatal" is that the current implementation
> terminates the program in that case. Since we are debating whether the
> behaviour is right, that is no grounds for an argument. We arbitrarily
> decide to make some errors fatal and others not, based on our best guess
> of what will be most useful for users.
>
Of course, but by "arbitrary" I mean some choice you make without good
arguments for one or the other side. Referring to a non-existent path and
trying to talk to a non-existent repository are two different things to
me. One might well argue that one of the cases should be treated like
"more fatal" than the other. I don't say I nececarily agree, though.
> > 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.
>
> Roughly; but "so you can use wildcards [that match more than just the
> intended files]" is only one example of a sloppy usage that is made
> "easier" by the decision. Similar cases do apply to URLs, e.g. "svn
> info $REPOS/branches/1.{0,1,2}.{0,1}" where you don't care if some of
> those combinations don't exist. So no, we shouldn't get rid of that
> behaviour just for URLs.
I think using wildcards that generate existing filenames is different from
explicitly listing (albeit in a compact form) paths, so just because we
ignore non-existent and unversioned WC paths in some cases doesn't
neceecarily mean we should ignore non-existent URLs. Again, I have no
strong feelings, I'm just pointing out that the two cases aren't
completely the same. If we want to go this route,we have more commands
that should continue after a non-existent URL. I tried svn ls for example.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 12 22:18:05 2005