[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tree conflicts - depth of comparison [was: svn commit: r33479 - trunk/notes/tree-conflicts]

From: Stephen Butler <sbutler_at_elego.de>
Date: Tue, 07 Oct 2008 01:15:45 +0200

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.

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_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-07 01:15:56 CEST

This is an archived mail posted to the Subversion Dev mailing list.