On Tue, 2008-10-07 at 01:15 +0200, Stephen Butler wrote:
> Quoting Julian Foad <julianfoad_at_btopenworld.com>:
> > On Mon, 2008-10-06 at 07:22 -0700, sbutler_at_tigris.org wrote:
> >> Author: sbutler
> >> Date: Mon Oct 6 07:22:49 2008
> >> New Revision: 33479
> >> Log:
> >> Update tree-conflict detection design document, treating files and dirs
> >> consistently. A tree conflict victim should not be updated/merged.
> >> * notest/tree-conflicts/detection.txt
> >> Revise and simplify use cases. Adapt supporting text to match.
> > Thanks, Steve. It's good that you have simplified the text by combining
> > "file" and "directory" descriptions. Some comments on "depth" support
> > are below, and one trivial remark on terminology.
> > The input of someone familiar with the "--depth" concepts would be
> > useful.
> > Under UC2:
> >> +[...] The check for
> >> +modifications continues to the "ambient" depth.
> > OK. I will examine what this means, and then compare it with UC5.
> > According to the book, "ambient" depth means the depth that is present
> > (and recorded) in the working copy, regardless of any "--depth" or
> > "--set-depth" argument specified in the update command.
> > Specifying that the check continues to the "ambient" depth means that
> > all changes present in the working copy will be noticed, even if they
> > are deeper than the "update" command is looking. For example:
> > [[[
> > $ svn status --verbose
> > A
> > A/B
> > M A/B/file
> > $ svn update --depth=immediates
> > C A
> > ]]]
> > Let's say that the incoming change wants to delete A. The update will
> > not delete A, because it will see that there is a change somewhere deep
> > inside A. Instead, it will raise a tree conflict.
> > That is good, I think.
> > Notice that the meaning is the same as if we were to specify that the
> > comparison continues to the full repository depth of the trees: there
> > cannot be any difference between the item "A" that was deleted in the
> > repository and the item "A" in the WC without there being a local
> > modification within the WC's "ambient" depth.
> > Under UC5:
> >> +For a directory, the comparison will descend to the depth specified in
> >> +the merge command. The merge depth is usually infinite, but in a
> >> +sparse working copy, the default merge depth is the "ambient" depth of
> >> +the given directory.
> > Here, the treatment of depth is different. This definition can fail to
> > detect a difference that exists between the directory tree that was
> > deleted in the source and the directory tree to be deleted in the
> > target, if the difference is already in the repository and the target WC
> > is sparse. Is this intentional? I wouldn't expect this.
> > For a behavioural definition, I would expect both "update" and "merge"
> > cases to define that "The comparison will descend to the full depth of
> > the tree, not restricted to any ambient or specified depth." Would you
> > agree?
> I would like to, but I feel my hands are tied by those pesky mixed
> For update, we are comparing a target repository revision to a working
> copy with mixed revisions. Beyond the ambient depth, there's in
> general no single repository tree (i.e., revision) that corresponds to
> the working copy. I don't see where we'd descend to.
There's no "single" repository tree, but there is a well-defined tree
which consists of the WC tree as far as it goes, plus, at each missing
entry, one sub-tree found in the repository at the revision and URL of
the missing item.
For "update", however, any such sub-tree cannot have modifications if it
is not in the WC, so we don't even need to check them.
(The same applies to a "switch". It doesn't matter that the tree we're
switching TO is different, as the comparison is with the tree we are
> For merge, in the reasonable case that the working copy has been
> updated to a single revision, descending to full depth is doable.
Even if it has not been updated to a single revision, we can still crawl
it on disk.
> But in general, focusing on the content (to the local depth) of the
> working copy is the way to go. To echo your email today regarding
> merge tests, in the merge target wc tree, the revision or URL of any
> item's BASE is uninteresting. The actual tree is our target, isn't
If by "the actual tree" you mean only those parts of the tree that are
present in the WC, then no, I don't think that is our target. The tree
that we are going to mark as deleted is not just the parts that are in
the WC but also any sub-trees that are missing from the WC. Think about
is as "what will be committed".
I am sure we will end up in trouble if we define that the comparison
intentionally ignores sub-trees that are missing from the WC. (If we
have to compromise the initial implementation because it is too
difficult to do a full comparison, that's another matter.)
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-07 18:37:21 CEST