[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn URL's with '..' elements

From: Ben Reser <ben_at_reser.org>
Date: 2005-02-24 20:08:59 CET

On Wed, Feb 23, 2005 at 12:50:03PM -0500, Chris Pickett wrote:
> 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.

The other thing that I had forgotten about which Josh brought up is the
symlink issue. I said it didn't matter for URLs but I was forgetting
file:/// URIs. Which are essentially local paths. When a .. is used
and a symlink is in the path it's completly ambiguous as to how to deal
with that. Should we just remove one path element or walk the path?

You can file an issue if you want. But I don't think we should fix this
because the issues are too big of a mess. I understand how it's handy.
But the use of it is ambigous.

Firefox deals with file:/// URLs but users don't use it that often and
it's not nearly as critical that it work right. But even various
command line tools don't implement it consistently:

$ ls -l /home/breser/foo-tmp
lrwxrwxrwx 1 breser breser 4 Feb 24 11:01
/home/breser/foo-tmp -> /tmp/

$ (cd /home/breser/foo-tmp/../; pwd)
/home/breser

$ ls -l /home/breser/foo-tmp/../
total 27
drwxr-xr-x 2 root root 2456 Jan 30 2004 bin/
drwxr-xr-x 3 root root 2056 Feb 21 22:58 boot/
drwxr-xr-x 1 root root 0 Dec 31 1969 dev/
[snip]

i.e. the root partition.

Firefox gives /home/breser if you ask fore
file:///home/breser/foo-tmp/..

It's stuff like this that makes me think we shouldn't implement it...

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 24 20:12:08 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.