Josh Pieper <jjp@pobox.com> writes:
> Philip Martin wrote:
>> Probably. I think we could also delete log files as we go provided
>> cleanup did apr_dir_read to identify the lowest numbered log file.
Well done! You ignored my thinko about deleting log files as we go;
the log files can only be deleted once the entries file has been
written.
> @@ -2083,6 +2153,19 @@
> /* If a conflict happens, then the entry will be
> marked "Conflicted" and will track either 2 or 3 new
> temporary fulltext files that resulted. */
Is the above comment now redundant?
> +
> + /* 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);
> +
> + SVN_ERR (svn_wc_merge (svn_path_join (base, txtb, pool),
> + svn_path_join (base, tmp_txtb, pool),
> + svn_path_join (base, base_name, pool),
> + adm_access,
> + oldrev_str, newrev_str, ".mine",
> + TRUE, &merge_outcome, diff3_cmd,
> + pool));
This is a bit unfortunate. I think I see what you are doing, the old
code could examine the wc state to get this information but in the new
code the notification callback is called before the log file is run.
A dry-run merge can be time consuming when dealing with large files,
although since only files with local mods are affected I guess it may
not be too bad in practice. I don't know if there are any
alternatives, I guess it's difficult to postpone the notification
callback.
Have you tested over ra_dav? I recall we had problems in the past
with wcprops during an interrupted update, although I can't remember
the exact details. It's possible we made the wcprops code robust
enough for this change to work.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 23 19:28:48 2004