Re: [PATCH] Single file merge tracking implementation. /merge-tracking/subversion/libsvn_client/diff.c

On Fri, 07 Jul 2006, Kamesh Jayachandran wrote:

> Thanks Dan for the review and refined patch.
> >>+ SVN_ERR(svn_fs_fs__change_txn_mergeinfo(txn, canon_path, value,
> >>pool));
> >>
> >> SVN_ERR(svn_fs_fs__change_txn_prop(txn,
> >> SVN_FS_PROP_TXN_CONTAINS_MERGEINFO,
> >>
> >
> >Seems like we'll be hitting this code path very often. Is this
> >canonicalization redundant in some instances? Can it be avoided, or
> >made specific to the "single-file merge" case?
>
> Originally tried to investigate why nodes under root are not
> canonicalized, did not have much success.

I'd like more information about this -- can you dig a little deeper?
Does this behavior also apply to children of the FS root when called
from do_merge()?

...
> >>+ if (ctx->notify_func2)
> >>+ {
> >>+ svn_wc_notify_t *notify
> >>+ = svn_wc_create_notify(merge_b->target,
> >>svn_wc_notify_update_update,
> >>+ pool);
> >>+ notify->kind = svn_node_file;
> >>+ notify->content_state = text_state;
> >>+ notify->prop_state = prop_state;
> >>+ (*ctx->notify_func2)(ctx->notify_baton2, notify, pool);
> >>+ }
> >
> >As with do_merge(), we'll be calling this notification function over
> >and over again for each revision range we merge into this file. In
> >both cases, not the right behavior. Instead, we need to aggregate the
> >notifications, and distill them into some reasonable form. When
> >notifications conflict, I think we want to give preference to latter
> >notifications.
>
> Could not understand it much would go through the same later and provide
> a fix for it.
...

Nailing this down in conjunction with the special casing for the
"svn:mergeinfo" housekeeping property makes sense.

I ripped out the UUID checking code (since this isn't a cross-repos
operation, despite what that comment looked like), made a few more
adjustments, and have committed this as r20471.

Thanks, Dan