Re: Handle WC local reverts which have modified our merge info

On Wed, 30 May 2007, Paul Burba wrote:

> Yesterday in IRC:
>
> <dlr> pburba: While you're at it, I think we can get rid of those
> "handle WC local reverts which have modified our merge info" comments in
> merge.c
> <dlr> I *think*
>
> Here is the code in question, in
> merge.c:do_merge()/do_single_file_merge():
>
> /* When only recording merge info, we don't perform an actual
> merge for the specified range. */
> if (merge_b->record_only)
> {
> if (merge_b->dry_run)
> {
> return SVN_NO_ERROR;
> }
> else
> {
> /* ### Handle WC-local reverts which have modified our
> merge
> ### info. */
> apr_hash_t *merges;
> SVN_ERR(determine_merges_performed(&merges, target_wcpath,
> &range, &notify_b,
> pool));
>
> /* If merge target has indirect mergeinfo set it. */
> if (indirect)
> SVN_ERR(svn_client__record_wc_mergeinfo(target_wcpath,
>
> target_mergeinfo,
> adm_access,
> pool));
>
> return update_wc_mergeinfo(target_wcpath, entry, rel_path,
> merges, is_revert, adm_access,
> ctx, pool);
> }
> }
>
> Dan,
>
> I'm not 100% sure exactly what these comments refer to. In the case
> where pre-existing local changes reverted *some* of the mergeinfo on
> TARGET_WCPATH, then trunk currently works correctly.

I'd assume so -- those comments predate all your recent great work
with WC eliding, and I don't think take into consideration that we now
always assume merge info to be correct -- that is, to take both repos
and WC direct and inherited merge info into consideration -- when
recorded in the WC.

> But if pre-existing local changes reverted *all* of the mergeinfo on
> TARGET_WCPATH and TARGET_WCPATH has no WC ancestor to inherit mergeinfo
> from, then merge, --record-only or not, doesn't work. But AFAICT this
> is a different problem altogether (i.e. we don't allow empty revision
> ranges to be set) and not something specific to --record-only. It just
> looks like this problem in fact:
>
> http://svn.haxx.se/dev/archive-2007-05/0592.shtml

Sounds like a separate issue. Let's discuss it at that thread.

> I removed the comments in r25203 as I'm pretty sure this is a separate
> issue, but if I'm off base in my understanding let me know. Also, if
> you have a moment to look at the above thread that would be great.

I saw, thanks Paul.