Mike, r25891 doesn't appear to handle Replace support for the 'svn
merge -r2:1 url' case which is blocking issue #2822 (by causing the
failure for revert test #15 w/ the patch in that issue). This
particular case does an implicit peg of HEAD, which is handled in the
block above the one quoted below (in which you've fixed the Replace
problem for history-sensitive merging).
In r25889, you changed the merge test case written by Senthil to
avoid this implicit use of a peg revision, and mentioned that "the
jury is still out (for me) on whether or not that use case is
expected to fail." Would you elaborate on this?
Thanks, Dan
> On Mon, 30 Jul 2007, cmpilato@tigris.org wrote:
>
>> Author: cmpilato
>> Date: Mon Jul 30 13:37:14 2007
>> New Revision: 25891
>>
>> Log:
>> Finish issue #2853 (do_single_file_merge() lacks comprehensive
>> "replace-style merge" capability).
>>
>> Prior to this change, merges performed on a single file failed to
>> honor the --ignore-ancestry flag, opting instead to always ignore
>> ancestry. This caused unexpected behavior when merging single-file
>> replacements.
>>
>> * subversion/libsvn_client/merge.c
>> (merge_file_added): Be a little more forgiving when calculation
>> copyfrom URLs for merge-added files.
>> (do_single_file_merge): Add 'ignore_ancestry' parameter, and use
>> it to
>> determine whether not a merge across unrelated file nodes should
>> be treated as a file modification or a delete+add. While here,
>> actually grow support for the delete+add case.
>> (discover_and_merge_children, svn_client_merge3,
>> svn_client_merge_peg3):
>> Pass 'ignore_ancestry' to do_single_file_merge().
>>
...
>> --- trunk/subversion/libsvn_client/merge.c (original)
>> +++ trunk/subversion/libsvn_client/merge.c Mon Jul 30 13:37:14 2007
...
>> @@ -2467,6 +2469,51 @@
>> path1 = NULL;
>> path2 = NULL;
>> }
>> + /* If we are not performing a pegged merge, but we also are not
>> + ignoring ancestry, then we need to check the relationship
>> between
>> + the two sides of our merge. */
>> + else if (! ignore_ancestry)
>> + {
>> + const char *location_url;
>> + svn_opt_revision_t unspecified_revision, *location_rev;
>> + unspecified_revision.kind = svn_opt_revision_unspecified;
>> +
>> + /* Try to locate the left side of the merge location by
>> tracing the
>> + history of right side. We do this only do verify that
>> one of
>> + these locations is an ancestor of the other. */
>> + err = svn_client__repos_locations(&location_url,
>> &location_rev,
>> + NULL, NULL,
>> + NULL,
>> + initial_path2 ?
>> initial_path2
>> + :
>> initial_URL2,
>> + &assumed_initial_revision2,
>> + &assumed_initial_revision1,
>> + &unspecified_revision,
>> + ctx, pool);
>> +
>> + /* If the two sides don't have an ancestral relationship,
>> that's
>> + okay. But because we are preserving ancestry, we have to
>> + treat a merge across those locations as a deletion of
>> the one
>> + and addition of the other. */
>> + if (err && err->apr_err == SVN_ERR_CLIENT_UNRELATED_RESOURCES)
>> + {
>> + is_replace = TRUE;
>> + svn_error_clear(err);
>> + err = SVN_NO_ERROR;
>> + }
>> + SVN_ERR(err);
>> +
>> + /* ### FIXME: We need to actual do some relationship
>> checks. */
>> + URL1 = initial_URL1;
>> + URL2 = initial_URL2;
>> + path1 = initial_path1;
>> + path2 = initial_path2;
>> + revision1 = &assumed_initial_revision1;
>> + revision2 = &assumed_initial_revision2;
>> + }
>> + /* And if we aren't performing a pegged merge but we are ignoring
>> + ancestry, then we don't care about the relationships between
>> the
>> + sides of our merge source, and happily accept them as they
>> are. */
>> else
>> {
>> URL1 = initial_URL1;
...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 31 02:07:48 2007