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
> revisions.
>
> 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
switching FROM.)
> 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
> it?
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.)
- Julian
---------------------------------------------------------------------
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