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?
> 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
---------------------------------------------------------------------
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-06 17:53:46 CEST