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 > 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 … > 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/? > 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. 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. > 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 ./^./. Alrighty then, Thomas -- Dr. Thomas Orgis HPC @ Universität Hamburg
