On 22. 5. 25 13:38, Dr. Thomas Orgis via dev wrote:
Am Tue, 20 May 2025 17:08:21 +0200
schrieb Branko Čibej<br...@apache.org>:
So, no, we don't currently have a syntax for relative URLs that would do
what you propose. I don't know offhand what all the ramifications would
be (other than, well, writing a bushel of tests for that), but if
someone steps forward with a patch, I expect we'd accept it.
OK. So I did not miss the existing functionality. A superficial but
important question would be about the user interface then. You seem to
suggest ^./some/wc/path
Eh, the syntax is the least important issue at this point. I do feel
that ^^ is too much of a good thing – it becomes ^^^^ on Windows, and
that's ... inelegant. :)
I'm sure we talked a lot about relative URLs on this list before,
including about what you propose.
The interesting bit then would be to see why it wasn't implemented.
Maybe there are strong reasons …
I'd have to dig in the list archives waaaay back. I don't remember.
There is, however, a "slight" problem:
the current implementation of repos-relative URLs doesn't look at the
working copy at all; indeed, ^/path works without a working copy. So
this is really an entirely new concept.
I am not sure how ^ would be resolved without a working copy. Where
does the information for the repo to look in come from? Or do you mean
in the code, there is no reference to working copy data besides the
repo info that has been gleaned from .svn/?
That was my complete braino, sorry. Of course we need a WC to resolve ^/
... I don't know what I was thinking.
And of course, if we support "^.", we obviously have to support
"^./any/relative/wc/path" in the same way.
Not sure what you mean. ^/ is the repo root. ^./ is the repo path of
the current working directory. Naturally, ^./some/path would be
some/path below the repo location of the current working directory.
Naturally? What if ^./foo/bar is the repos URL of the path foo/bar below
the current directory in the working copy? There are two, equally valid
interpretations, and I sure can't see offhand which one is better.
Even if I have not checked out that part, I would expect to address the
path in the repo. I don't see where any/relative/wc/path comes in as
something special. I may be simplifying, just thinking about ^./ being
a shorthand/string replacement. I'd expect relative paths like ^./../
to work for the parent of the current working directory in the repo.
As they do currently for ^/../, I believe.
I don't remember how we deal
with actual names in the working copy named "^", but I'm sure there's
The URLs have them urlencoded. Local work … when I mkdir ^foo, it's no
issue. It is just a local path. Trouble is with creating a directory ^/.
svn add ^/foo
will fail as it is resolved to the repo. But:
svn add ./^/foo
will work. I guess there is no special handling, you just have to avoid
^/ at the beginning of any argument that is suppoed to refer to a local
path. This would extend to ^./ syntax, that one would need to address
an actual local directory via ./^./.
OK, at least we're consistent then.
-- Brane
