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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 17 19:01:39 2007