Ben Reser wrote:
> On Tue, Feb 22, 2005 at 09:41:23PM -0500, Josh Pieper wrote:
>
>>Those reasons, plus it has not well-defined symantics when used over
>>symlinks. I have some IRC discussions from last July where the merits
>>were discussed if anyone is interested.
>
>
> Ohh yeah forgot about the symlink issue. But the symlink issue doesn't
> apply to URLs. But right now we're using the same functions to
> canonicalize URLs and local file paths so that's why it matters for
> those that wonder.
>
Ok, well thanks for the explanations. From my perspective:
1) Firefox understands '..' in URL's, and so does wget, and probably so
do a number of other common programs (I didn't try any others).
2) As I stated before, it helps to have '..' if you use environment
variables in your shell to save typing.
3) It's kind of frustrating because '..' is allowed if I'm using it to
refer to a working copy (as recent as 1.1.3).
4) IMO confusing the user because the error message might not match the
input is not such a big problem and could be prevented by giving more
verbose output as to what's going on in the event of an error.
5) As for extending the URI standard, all that's being asked for is to
recognize '..' as a directory name, not everything that my shell (bash)
understands.
So, if you can work around the oher issues you've stated here (problems
with externals, canonicalizing input, possible buffer underflows), I
think there's evidence from other projects to suggest this is useful.
I'll file an RFE (P5) if you like and if there's a chance you'll address
this in the future. I understand it's not a very high priority.
Cheers,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 23 18:52:10 2005