On Dec 7, 2007 7:20 PM, Julian Foad <julianfoad@btopenworld.com> wrote:
> 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.
>
Well I was thinking in terms of this relative url support. But now
that I think about it I guess if you type in a path "under" the
externalized directory then you expect it to point to the *other* repo
anyway. It just took me a bit to absorb this usage that I didn't know
about.
>
> > 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 don't understand the difference here. Is it because of externals?
Or are you talking about the different protocols supported by
Subversion (http, svn, or ssh)?
>
> 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.
>
Sounds familiar :)
> * 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?
>
Yep, sure is. I've been thinking on the implementation for a while
but have been to busy or too tired to get started on it. But starting
on it is one of my goals for this weekend.
> - Julian
>
Troy
--
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 8 16:12:28 2007