On Nov 17, 2007 12:01 PM, Julian Foad <julianfoad@btopenworld.com> wrote:
> Troy Curtis Jr wrote:
> > On Nov 16, 2007 12:30 AM, David Glasser <glasser@davidglasser.net> wrote:
> >>On Nov 15, 2007 9:13 PM, Troy Curtis Jr <troycurtisjr@gmail.com> wrote:
> >>
> >>>I have implemented relative url support for every subcommand that makes sense.
> >>>Every command that had an existing test set has a new test function to test it
> >>>with relative urls. Comments?
> >>
> >>Every call to svn_wc_get_absolute_url and
> >>svn_wc_get_absolute_url_array from your client code passed "." as the
> >>wc path. I don't see how this is appropriate; you should be able to
> >>use
> >>
> >> $ svn switch ^/trunk /absolute/path/to/wc
> >>
> >>for example. I don't know of anything else in the client which
> >>defaults to current directory ignoring arguments...
>
> Well yes, "relative to what" is a crucial piece of the design. It did get
> mentioned before and we said "yeah, OK, let it refer to the current directory"
> but in examples like the one you gave I agree that might not be acceptably
> surprise-free behaviour.
>
> Troy, could you do a bit of analysis: prepare a list indicating which commands
> (and variants thereof) would be best meaning "relative to current directory",
> which would be best relative to some other argument (what, exactly?), and any
> problems with potentially multi-repository commands or whatever. Tell us if you
> think there could be a useful and consistent solution other than just meaning
> "this current directory" for all commands. If you're not sure what would be
> best for some particular commands because you're not sure how they're normally
> used, say so and we can fill in the gaps.
>
> (n.b. I'd say "another argument" should include the implicit "." argument that
> is assumed by many commands.)
>
> If that "switch" command above were to be the only command that seems
> counterintuitive, you could argue that consistency across all commands
> overrules it.
>
> Also think briefly about whether it would be sane for "^" to have a multi-part
> definition, something like (but could be quite different from):
>
> * the repository of the other arguments, when present and consistent; else
> * the repository of the current working directory, or
> * the repository configured by some per-user setting (e.g. in
> .subversion/config or an environment variable)
>
> That's getting too complex for now but the thought of doing that in the future
> might influence the decision of what simpler rule to make for now.
>
> Another option might be to make this syntax, for now, available only when the
> command acts on NO working copy. Doesn't sound like it would be useful enough
> with merge commands but, again, thinking about it might lead to some good idea.
> Or if "^" is used then the other arguments shall not refer to absolute WC
> paths, or shall not refer to WC paths outside ".", or something like that.
>
> Basically I'm asking you to examine the alteratives and find what you think is
> the best meaning and show us why. Bear in mind that if we add functionality now
> we can't generally change it later, so the best thing might be to support it
> only in types of command where we agree it's The Right Thing and leave it
> unsupported in other cases, hoping to do better in those cases later.
>
> And don't let worries about how any of this could be implemented influence the
> decision!
>
> Thanks.
> - Julian
>
>
>
> > Yeah I guess that's true, and obviously I gave it the option of having
> > the value passed in. However, I was simply thinking of the meaning of
> > the '^/' as the root url for the current directory. It seemed like I
> > thought of a couple of cases where using the values in the argument
> > list would be confusing but I can't think of it. I guess it does make
> > sense at least on those commands that always have some working copy
> > path to affect, like svn switch and merge.
> >
> > So what makes the most sense. Given an array of targets (for a
> > general case) dig through and find a working copy path (if there is
> > one) and use it's root url, else use the current directory? Or only
> > look at the argument list on those functions that are guaranteed to
> > have a working copy path as an argument? I think that is only switch
> > and merge right? At least for an existing working copy. I did add
> > code to checkout so that you could do something like "svn co
> > ^/branches/a ../a" while in a trunk working copy, but obviously in
> > that case I couldn't not use the given wc path.
> >
> > Ultimately I thought it was simpler to thing of the substitution as
> > 'root url of the current directory' since it doesn't really had any
> > new "features" and it's just a shortcut.
>
>
As far as I know the only commands that allow multi-repository
arguments is 'svn switch --relocate' and command which simply operate
by iterating through the argument list, executing the API call for
each argument in turn (i.e. info, cat, blame). Is this correct?
Multi-repository arguments are really the only difficult or confusing
case that I could come up with if you were to use "look at the other
arguments" method.
My primary reason for going with the "use current working directory"
approach was simplicity and ease of understanding the concept. It's
very easy to just say "^/ is replaced with the root url of the current
directory" and it seemed like to me it still caught almost all of the
"what do I expect it to do" situations. For example, when I'm merging
I'll most likely be in the directory I'm merging into (though I
understand that is not required), when I'm creating a new branch, I'll
probably be in a working copy of the same repo.
However, you and David's comments have made me realize that it
probably is a bit TOO simplistic. In order to use relative urls in
the creation of a branch I need a working copy from "somewhere" in the
repo. So I guess it does make sense. That said I definitely think that
the meaning should not change from command to command. Because the
syntax is the same the meaning should be the same. file:// does not
have any different meaning between commands.
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
Basically a "whatever root url was last encountered". I think it
would complicate understanding what the syntax does and make adoption
more difficult. Plus it only really helps in what I am pretty sure is
a very minor use case.
And I know that you said not to let implementations worry me, but
requiring a consistent root url among all the non-relative-url
arguments would mean that you would HAVE to "hit" each target to
determine it's root repo url. Seems like a waste.
So I guess really the commands that would be best served with the
"current directory" method are those that have the current directory
in their arguments (either explicitly or implicitly). It is a
somewhat simpler concept to explain than the "look to other
arguments", but not by much and it does make an uncharacteristic
assumption (CWD, period).
As a check, are there any mult-repo commands that I'm missing?:
* switch --relocate
* blame
* cat
* info
* list
* propget
* proplist
I'd say, considering this list that there shouldn't be a big issue
with going with the "first-come" algorithm. Comments?
Troy
--
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 21 06:46:44 2007