Can we have a few more people's opinion on what "The Repository" should mean
exactly? See proposed rules below.
Troy Curtis Jr wrote:
> On Nov 29, 2007 7:20 PM, Julian Foad <julianfoad@btopenworld.com> wrote:
>>Troy Curtis Jr wrote:
>> svn propdel pname ^/trunk/subproj1 ^/branches/v1.0/subproj1
>>
>> svn propdel pname ^/trunk/subproj2 ^/branches/v1.0/subproj2
>>
>> svn propdel pname subproj3 ^/branches/v1.0/subproj3
>>
>> svn propdel pname subproj4 ^/branches/v1.0/subproj4
>>
>>Half way through, we realised that typing the subdirectory name is shorter than
>>the relative URL syntax and does the same thing (assuming the more precisely
>>defined rules at the end of this email). No problem.
>>
>>Now suppose that "subproj2" and "subproj3" are "svn:external" directory trees
>>from a different repository. The behaviour changes now in ways which are less
>>initially obvious:
>>
>> ^/branches/v1.0/subproj2 => refers to *this* repository
>>
>> ^/branches/v1.0/subproj3 => refers to *subproj3's* repository
>>
>>I'm not saying the result of this example is "bad", just that it's the sort of
>>non-obvious edge case I'd been wanting to find and examine.
>
> Hum, my knowledge of the the externals support is pretty limited. Can
> you reference "through" and externals directory? i.e. if
>
> svn:external "file://repo2" -> repo2_dir
>
> [repo1_wc] # svn info file://repo1/repo2_dir/trunk
>
> Would get you repo2's trunk info?
Absolutely! That's pretty much the original purpose of "externals".
> That could definitely lead to some
> confusion and I was not aware that it could be used like that (if it
> can).
I don't see "externals" leading to too much confusion, but maybe I'm unaware
because actually I don't use them.
> Sounds good, I guess now we can talk a little implementation detail?
>
> - First, if the urls given do NOT have the same repository root URL,
> should it be an error, or should it just fall through the first
> condition and into the "current directory" behavior?
It should throw an error.
I'll re-phrase my/our currently proposed rules more completely:
* If a command-line argument representing a "target" starts with "^/" (before
local path style translations), then:
1. The prefix "^/" shall be removed.
2. The remainder shall not start with "/", else throw an error.
3. The remainder shall undergo the same validations and translations as are
applied to the within-repository part of an absolute URL.
4a. If any other target argument (including any
implicit target) is a non-relative URL or a working
copy path:
The remainder shall be interpreted relative to
the repository root URL of all such other targets.
(These URLs are all the same, else throw an error.)
4b. Otherwise:
The remainder shall be interpreted relative to
the repository root URL of the current directory.
(The current directory is a working copy, else
throw an error.)
Note that in case (4a) all of the repository root URLs must be the same, not
just be URLs pointing to the same repository.
I am still pondering whether one of the following alternatives would provide a
better foundation for future expansion of the feature:
* One syntax for "relative to the current directory's repo" and another for
"relative to the other arguments' repo".
* Support only "relative to the current directory's repo" for the time being.
* Support only "relative to the other arguments' repo" for the time being.
I'd like to hear others' opinions.
This needn't delay the initial implementation as most of it will be similar for
any of these possibilities.
> - For speed concerns it would be really nice if we could just use the
> first full url (or wc path) we come to get the repo root url. This
> would be valid if we do not support urls with multiple root urls.
> However, the error might be a little non-obvious if the user DID
> specify urls spanning multiple repositories. I'm not sure.
Forget your speed concerns! Seriously. First design it to be Right, even if it
feels like it would have to be slow, so that we at least know what we're aiming
for and how to test it. Then, if it turns out to be impossible to implement
efficiently, we'll have to either compromise the design or modify the
supporting architecture, but I almost guarantee that no such problem will
materialise :-)
Is this OK to be going on with? Maybe you've already started?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 8 02:20:58 2007