"Troy Curtis Jr" <troycurtisjr@gmail.com> writes:
> So I do think that part of your idea would certainly be a better design:
> * the repository of the other arguments, else
> * the repository of the current working directory
>
> One question is: Given a list of targets pointing to different
> repositories should it be a first-come situation? Or like you
> mentioned, it only works if all the targets point to the same repo and
> just bails if that isn't true. I certainly wouldn't want to have
> something like this:
>
> svn ls http://svn/repo1/trunk ^/branches/a http://svn/repo2/trunk ^/branches/b
>
> Where:
> ^/branches/a -> http://svn/repo1/branches/a
> ^/branches/b -> http://svn/repo2/branches/b
We're going to have to get into the users' heads here. Instead of
thinking about the rules programatically, let's look at the user's
instinct, which is probably going to be:
* the repository of the "most recently/nearest mentioned repository"
...where "mentioned" could be explicit or implicit. If no
repositories were named, the current directory is the obvious choice.
If there is only one other repository on the command line, then it's
probably the right choice. But beyond that, I think we'd have to go
through all the Subversion commands, figure out roughly how many URLs
each could be invoked with and what they mean, and imagine in each
case what a user would expect a relative URL to mean in each position.
That doesn't mean that's what we must implement! It's just the best
way to gather data to build ourselves a general principle.
There isn't an easy answer here, but there probably will be a useable
and intuitive one, if we tackle it right.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 21 22:08:47 2007