On Mon, Feb 04, 2002 at 07:57:27AM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gstein@lyra.org> writes:
>...
> > Even something as simple as "svn stat" will create the question of
> > "but wait, what repository is that from?" And that "svn stat -u" for
> > a single directory could create a bunch of sessions.
>
> By this argument, Greg, we shouldn't allow 'svn switch' at all.
> You're describing a complexity of having *any* disjoint URLs in the
> working copy at all.
Only allowing the disjointedness to occur at directories means that all the
files in that directory are from the same repos/dir. The notion of a
"working copy root" is based on a directory, and it breaks down if you now
have files that can, themselves, be disjointed (they aren't exactly roots).
Only are recursion points (directories) do we need to test for a new root.
If you allow files, then *every* file must be tested to see whether it
actually resides in its parent, or if it comes from somewhere else.
> And you're confusing two issues here:
>
> 1. Allowing 'disjoint' urls in a working copy
>
> 2. Allowing urls from different repositories in a working copy
Nah. The point is allowing a file to come from somewhere other than its
enclosing directory.
Every place where we get a list of files in a directory will now have to
possibly manage the fact that those files could come from different places.
Before, it was constrained just to directories, and we had that managed
through the svn_wc_is_wc_root() function.
>...
> But regarding issue #1, this is going to happen if we allow 'svn
> switch' to exist at all. The thing is, Mike/Karl/I have already
> walked through all the hairy details of exactly how commits and
> updates are going to deal with disjoint urls. And it's all documented
> in the last section of notes/merging-and-switching.txt.
Sure... and I note that it only refers to subdirectories.
> In a nutshell: for updates, we're going to build 2 transactions that
> contains disjoint things linked in, so that the tree delta applies
> cleanly to the working copy. For commits, we're going to need to
> collect all changed paths (and urls) in memory, so that we can start
> the commit-drive at at the common parent url.
Yup... that's all in there.
> So please, please, please... refute this plan. Or explain why
> allowing a disjoint file url is *any* different than allowing a
> disjoint directory url. I can't see the difference.
The files returned by listdir() may not actually live in the parent you're
listing. Every time a person wants to simply refer to a file, there is a lot
more logic involved to see whether it truly lives in the parent, or if it
came from somewhere else.
>...
> I agree with you here. My last commit was the wrong approach. I'm
> going to revert all that stuff; it will be *much* cleaner to just do
> a full get_file(), rather than trying to push confusing semantics
> through an editor. Thanks for the dose of reality. :-)
Coolness. Note that ra_dav currently filters some properties in its
get_file. It shouldn't do any filtering, but ought to just return every
property. The caller can figure out what they want, where to put it, etc.
(e.g. bugfix needed; I imagine you'll get there first; otherwise, it will be
done as part of a larger property cleanup)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:04 2006