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

Re: svn commit: r1303016 - in /subversion/trunk/subversion: include/private/svn_client_private.h libsvn_client/merge.c svn/cl.h svn/main.c svn/merge-cmd.c

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Thu, 22 Mar 2012 12:04:41 +0200

Julian Foad wrote on Thu, Mar 22, 2012 at 08:54:09 +0000:
> Daniel Shahaf wrote:
> > julianfoad_at_apache.org wrote:
> >> http://svn.apache.org/viewvc/subversion/trunk/subversion/include/private/svn_client_private.h?rev=1303016&r1=1303015&r2=1303016&view=diff
> > ==============================================================================
> >> --- subversion/trunk/subversion/include/private/svn_client_private.h
> >> +++ subversion/trunk/subversion/include/private/svn_client_private.h
> >> +/* Perform a symmetric merge.
> >> + *
> >> + * Merge according to MERGE into the WC at TARGET_WCPATH.
> >> + */
> >> +svn_error_t *
> >> +svn_client__do_symmetric_merge(const svn_client__symmetric_merge_t *merge,
> >> +                              const char *target_wcpath,
> >> +                              svn_depth_t depth,
> >> +                              svn_boolean_t ignore_ancestry,
> >
> > What does IGNORE_ANCESTRY mean in the context of symmetric merge?  In
> > particular, is it meaningful for the second merge in a 'sync A->B,
> > sync A->B' scenario?
>
> Clearly I need to fill in the doc strings.
>
> IGNORE_ANCESTRY doesn't affect the high level operation of the merge, it only affects how file diffs are shown -- even if the source and
> target file are not historically related it will show a diff rather than
> a delete and an add of the file -- or something similar to that.  From svn_client_merge4():
>
>  * Use @a ignore_ancestry to control whether or not items being
>  * diffed will be checked for relatedness first.  Unrelated items
>  * are typically transmitted to the editor as a deletion of one thing
>  * and the addition of another, but if this flag is TRUE, unrelated
>  * items will be diffed as if they were related.
>

So, IGNORE_ANCESTRY controls how the tree delta is communicated. Okay.
I was going by `svh help`, and the first mention there was effectively
"Ignore mergeinfo on the source when computing the merge" -- hence my
question.

> >> +                              svn_boolean_t force,
> >> +                              svn_boolean_t record_only,
> >> +                              svn_boolean_t dry_run,
> >> +                              const apr_array_header_t *merge_options,
> >> +                              svn_client_ctx_t *ctx,
> >> +                              apr_pool_t *scratch_pool);
>
> >> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/merge.c?rev=1303016&r1=1303015&r2=1303016&view=diff
> > ==============================================================================
> >> --- subversion/trunk/subversion/libsvn_client/merge.c
> >> +++ subversion/trunk/subversion/libsvn_client/merge.c
> >> @@ -10864,3 +10864,409 @@
> >> +/* */
> >> +static svn_error_t *
> >> +find_symmetric_merge(repo_location_t **yca_p,
> >> +                    repo_location_t **base_p,
> >> +                    repo_location_t **mid_p,
> >> +                    source_and_target_t *s_t,
> >> +                    svn_client_ctx_t *ctx,
> >> +                    apr_pool_t *result_pool,
> >> +                    apr_pool_t *scratch_pool)
> >> +{
> >> +  repo_location_t *yca, *base_on_source, *base_on_target, *mid;
> >> +
> >> +  yca = apr_palloc(result_pool, sizeof(*yca));
> >> +  SVN_ERR(svn_client__get_youngest_common_ancestor(
> >> +            NULL, &yca->url, &yca->rev,
> >> +            s_t->source->url, s_t->source->rev,
> >> +            s_t->target->loc.url, s_t->target->loc.rev,
> >> +            ctx, result_pool));
> >> +  *yca_p = yca;
> >> +
> >> +  /* Find the latest revision of A synced to B and the latest
> >> +  * revision of B synced to A.
> >> +  *
> >> +  *  base_on_source = youngest_complete_synced_point(source, target)
> >> +  *  base_on_target = youngest_complete_synced_point(target, source)
> >> +  */
> >> +  SVN_ERR(find_base_on_source(&base_on_source, s_t,
> >> +                              ctx, scratch_pool, scratch_pool));
> >> +  SVN_ERR(find_base_on_target(&base_on_target, &mid, s_t,
> >> +                              ctx, scratch_pool, scratch_pool));
> [...]
> >> +  /* Choose a base. */
> >> +  if (base_on_source
> >> +      && (! base_on_target || (base_on_source->rev > base_on_target->rev)))
> >> +    {
> >
> > The last part of this condition seems arbitrary: in the criss-cross
> > scenario, the order in which the 'criss' and the 'cross' are
> > committed shouldn't affect the base the algorithm chooses.
>
> Yes, that's true for a criss-cross.  However, it's not a problem for
> normal cases; criss-cross is a rare case.  As I wrote in the
> criss-cross merge section of
> <http://wiki.apache.org/subversion/SymmetricMerge>, in that case we
> probably should consider the relative ages of A1, B1, A3, B3, and A2,
> but I haven't yet thought about what's the best way to compare them.
>

In other words, work in progress. Fair enough.

Cheers,

daniel

> >> +      *base_p = base_on_source;
> >> +      *mid_p = NULL;
> >> +    }
> >> +  else if (base_on_target)
> >> +    {
> >> +      *base_p = base_on_target;
> >> +      *mid_p = mid;
> >> +    }
> >> +  else
> >> +    {
> >> +      /* No previous merge was found, so this is the simple case where
> >> +      * the base is the youngest common ancestor of the branches.  We'll
> >> +      * set MID=NULL; in theory the end result should be the same if we
> >> +      * set MID=YCA instead. */
> >> +      *base_p = yca;
> >> +      *mid_p = NULL;
> >> +    }
> >> +
> >> +  return SVN_NO_ERROR;
> >> +}
>
> Thanks.
>
> - Julian
Received on 2012-03-22 11:05:27 CET

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