Re: [PATCH] Optimize svn up/svn switch with internal diff3

"Erik Huelsmann" <ehuels@gmail.com> writes:

> Currently we dry-run-merge and later real-merge during 'svn up'/'svn
> switch'. This is to support interactive merge tools. However, most
> setups seem to use our internal merge, which doesn't need this
> behaviour.

Sounds good.

> --- subversion/libsvn_wc/update_editor.c (revision 20223)
> +++ subversion/libsvn_wc/update_editor.c (working copy)
> @@ -2070,7 +2070,8 @@
> newrev_str = apr_psprintf(pool, ".r%ld",
> new_revision);
>
> - /* Merge the changes from the old-textbase (TXTB) to
> + /* When using external diff:
> + Merge the changes from the old-textbase (TXTB) to
> new-textbase (TMP_TXTB) into the file we're
> updating (BASE_NAME). Either the merge will
> happen smoothly, or a conflict will result.
> @@ -2078,12 +2079,13 @@
> and keyword translation, and diff3 will insert
> conflict markers for us. It also deals with binary
> files appropriately. */
> - SVN_ERR(svn_wc__loggy_merge(&log_accum, adm_access,
> - base_name, txtb, tmp_txtb,
> - oldrev_str, newrev_str, ".mine",
> - pool));
> + if (diff3_cmd)
> + SVN_ERR(svn_wc__loggy_merge(&log_accum, adm_access,
> + base_name, txtb, tmp_txtb,
> + oldrev_str, newrev_str, ".mine",
> + pool));
>
> - /* Run a dry-run of the merge to see if a conflict will
> + /* Run (a dry-run of) the merge to see if a conflict will
> occur. This is needed so we can report back to the
> client as the changes come in. */
> base = svn_wc_adm_access_path(adm_access);
> @@ -2091,12 +2093,14 @@
> /* ### FIXME: We force use of the internal diff3 here
> because we don't want to run a graphical external
> diff3 twice. See issue 1914. */

That comment would need updating.

> + /* Dry-run iff resorting to external diff for real merge */
> SVN_ERR(svn_wc_merge2(svn_path_join(base, txtb, pool),
> svn_path_join(base,
> base_name, pool),
> adm_access,
> oldrev_str, newrev_str, ".mine",
> - TRUE, &merge_outcome, NULL, NULL,
> + diff3_cmd != NULL, /* dry run */
> + &merge_outcome, NULL, NULL,
> pool));

This now makes changes in the working copy without using the log file
mechanism. The second merge, the one that made all the changes in the
past, does use log files. Now the log file code have always been a
bit of a tricky area, I'm not sure we get it right at present, but is
your change doing the right thing?

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org