You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stephen Butler <sb...@elego.de> on 2008/10/06 23:15:45 UTC
Re: Tree conflicts - depth of comparison [was: svn commit: r33479
- trunk/notes/tree-conflicts]
Quoting Julian Foad <ju...@btopenworld.com>:
> On Mon, 2008-10-06 at 07:22 -0700, sbutler@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.
For merge, in the reasonable case that the working copy has been
updated to a single revision, descending to full depth is doable.
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?
Regards,
Steve
>
>
>> For each directory, it could retrieve the corresponding dir entry from
>> -the repository as it existed in the merge-left source of the merge,
>> -and compare the two for equality, i.e. check whether all fields in
>> -the svn_dirent_t returned by the repo match their corresponding
>> -attributes of the directory as found in the working copy.
>> +the repository as it existed in the merge-start source of the merge,
>> +and compare the two for equality, i.e. check whether all fields in the
>> +svn_dirent_t returned by the repo match their corresponding attributes
>> +of the directory as found in the working copy.
>>
>> -The left-merge revision shall be a new additional parameter to
>> +The merge-start revision shall be a new additional parameter to
>> merge_dir_deleted(). The ra session needed to contact the repository
>> via the get_dir() method is already contained in the merge baton which
>> is passed to merge_dir_deleted().
>
> This change is just replacing "merge-left" with "merge-start", but AFAIK
> "merge-left" is the established and consistently used terminology.
>
> - Julian
>
>
>
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tree conflicts - depth of comparison [was: svn commit: r33479
- trunk/notes/tree-conflicts]
Posted by Julian Foad <ju...@btopenworld.com>.
On Tue, 2008-10-07 at 01:15 +0200, Stephen Butler wrote:
> Quoting Julian Foad <ju...@btopenworld.com>:
>
> > On Mon, 2008-10-06 at 07:22 -0700, sbutler@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org