Let's just choose the topmost interpretation; it's fair to consider
everything below the repos dir to be owned by the repos.
Greg Stein <gstein@lyra.org> writes:
> We talked at length about that. There is no need for a user to know what
> part of an HTTP URL refers to the repository and which is within. To the
> user, a URL such as http://www.lyra.org/some/path/goes/here/then/a/file.c is
> simply a versioned item.
>
> We've been through this before (what was it? an hour on the phone?). I'll
> keep talking if you really want to. I'd rather not, though.
>
> [ and I'm awfully stubborn about not separating them; the separation is an
> artifact/legacy of CVS, rather than a necessity ]
I'm still curious, though: what harm? :-)
> > Here's a weird situation: suppose I specify a checkout of
> >
> > file:/usr/local/svn/foo/bar/baz/bop
> >
> > And suppose that an svn repository (a bunch of berkeley db files)
> > lives in /usr/local/svn/. But ALSO suppose that another svn repository
> > lives in /usr/local/foo/bar/ ! Which repository should be used?
>
> 1) Who says we should be supporting subdirectories from an SVN repository?
> Why isn't that directory considered "owned" by SVN and offlimits to
> monkeying around?
>
> 2) Choose one interpretation and state that as the definition. This doesn't
> have to be difficult.
>
> > You might say, "the shorter repos path should be used, rather than the
> > deeper one". After all, I *think* that this is what would happen if
> > you created a <directory> mapping nested within another <directory>
> > mapping into `httpd.conf', no? The higher-up directory mapping would
> > always win.
>
> Doesn't matter what the server happens to do. This is a different case, so
> the analogue doesn't apply.
>
> > Of course, then, what do you do if you *want* to access the nested
> > repository? You can't. But it's not a problem if we separate the two
> > paths from the beginning.
>
> It's also not a problem if you disallow it, or if you choose one form
> (top-most or bottom-most) as the destination and leave it at that.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:21 2006