Stefan and Stephen,
I have been trying to understand your proposal in detail.
Would you be able to help me by updating this document in the light of the
comments that followed so far, and with one further consideration which is this:
I am having difficulty understanding your proposal in detail because it is
written in terms of the fields of merge_cmd_baton_t, but without saying exactly
where and when you mean to apply these rules. Could you try to write it
primarily in terms of universal truth concepts, like
"If it is possible to determine a common ancestor, then ..."
instead of
"If the 'is_ancestor' field is true, then ...".
That would help me a lot.
Thanks.
- Julian
Stephen Butler wrote:
> Hello tree-conflict fans,
>
> The first phase of tree conflict detection is available in the tree-
> conflicts feature branch. See this post for a recap of the current
> functionality implemented by this branch:
>
> http://svn.haxx.se/dev/archive-2008-01/0296.shtml
>
> In extending the current tree-conflict-detection scheme to cover
> 'svn merge', we want to avoid presenting the user a lot of apparent
> tree conflicts that involve files with no common ancestry. To weed
> out these false positives, we have to query the repository. Our
> current plan is described below, arranged according to use case.
> The use cases are described in the recap email above and in
> notes/tree-conflicts/use-cases.txt.
>
> We would be grateful for any feedback.
>
> Thanks,
> Steve
>
>
> ==========
> USE CASE 4
> ==========
>
> A file modified in the merge diff does not exist at the current URL.
> If a file at the current URL has been deleted in the parent dir's
> history, then we might have a tree conflict.
>
> A tree conflict exists if all of the following predicates are true:
>
> 1. The merge operation is compatible with tree conflict detection:
> We check specific fields of the merge-command baton (of type
> merge_cmd_baton_t). If all of the following boolean fields have
> the given values, we might have a tree conflict.
>
> a. (same_repos == TRUE) Both of the source URLs, merge-left and
> merge-right, must be in the same repository.
>
> b. (sources_ancestral == TRUE) The merge-left URL given to the
> merge command must be an ancestor of the merge-right URL.
>
> c. (ignore_ancestry == FALSE) The rest of the predicates below
> depend on ancestry queries, so if the user wants to ignore
> ancestry there's not much point in looking for tree conflicts.
>
> d. (record_only == FALSE) A record-only merge operation updates
> mergeinfo without touching files.
>
> 2. The file at merge-left is an ancestor of the file at merge-right:
> We call svn_client__get_youngest_common_ancestor(). If the YCA
> is the merge-left file, we might have a tree conflict. Note that
> this is a more specific query than #1b above.
>
> 3. In the history of the current directory, a file by this name has
> been deleted: In the repository, we will call the function
> svn_repos_deleted_rev(), passing a "start" revision in which the
> file existed and receiving a "deleted" revision in which the file
> was deleted. But first we have to choose a valid "start" revision,
> which is a bit tricky since we don't yet know whether the file
> ever existed in the current directory.
>
> a. The parent dir and the corresponding dir at merge-left have
> a common ancestor: We pass the two directories to
> svn_client__get_youngest_common_ancestor(). If a common
> ancestor exists, we might have a tree conflict.
>
> b. The file existed in the parent dir's common-ancestor revision:
> If svn_ra_check_path() says that a file by that name existed
> in the parent dir at the common-ancestor revision, we might
> have a tree conflict.
>
> c. The file has been deleted in the parent dir between the
> common-ancestor revision and the working copy's base revision:
> We call svn_ra_get_deleted_revnum(), passing it the common-
> ancestor revision as the "start" revision and the base revision
> as the "end" revision. Note that this function does not yet
> exist in the remote-access layers. We'll have to implement it.
>
> 4. The file at merge-left and the file deleted in the parent-dir's
> history have a common ancestor: We pass the merge-left file and
> the "last surviving revision" of the file, derived from #3c above,
> to svn_client__get_youngest_common_ancestor(). If they have a
> common ancestor, we have a tree conflict (finally!).
>
>
> ==========
> USE CASE 5
> ==========
>
> An existing file is deleted by the merge diff. We don't want to lose
> any text changes that are unique to the file at the current URL.
>
> A tree conflict exists if all of the following predicates are true:
>
> 1. The merge operation is compatible with tree conflict detection.
> Same as #1 in use case 4.
>
> 2. The current file and the file at merge-left have a common
> ancestor: We can call svn_client__get_youngest_common_ancestor().
> If the ancestor exists, we might have a tree conflict.
>
> 3. The text of the current file does not match the text of the
> "last surviving revision" of the file after merge-left: The last
> survivor is found by passing svn_ra_get_deleted_revnum() the
> merge-left revision as "start" and the merge-right revision as
> "end". Thankfully, this is simpler than #3 in use case 4. I
> think we can call svn_client_diff_summarize2() to compare the
> files. If there is a text difference, we have a tree conflict.
>
>
> ==========
> USE CASE 6
> ==========
>
> A file deleted by the merge diff does not exist at the current URL.
> If a file at the current URL has been deleted in the parent dir's
> history, then we might have a tree conflict.
>
> A tree conflict exists if all of the following predicates are true:
>
> 1. The merge operation is compatible with tree conflict detection.
> Same as #1 in use case 4.
>
> 2. In the history of the parent directory, a file by this name has
> been deleted. Same as #3 in use case 4.
>
> 3. The file at merge-left and the file deleted in the parent-dir's
> history have a common ancestor. Same as #4 in use case 4.
>
> It would be nice to skip the tree conflict if the double-delete is
> caused by two rename operations that have the same destination.
> But we have to mark this as a tree conflict due to the current lack
> of "true rename" support. See notes/tree-conflicts/detection.txt
> for more on this topic.
>
--
http://www.foad.me.uk/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-22 12:53:43 CET