On Tue, Mar 16, 2010 at 15:59, Philip Martin <philip.mar...@wandisco.com> wrote: > Greg Stein <gst...@gmail.com> writes: > >> On Tue, Mar 16, 2010 at 13:11, <phi...@apache.org> wrote: >>>... >>> +++ subversion/trunk/subversion/libsvn_client/copy.c Tue Mar 16 17:11:15 >>> 2010 >>>... >>> @@ -1150,15 +1149,13 @@ wc_to_repos_copy(svn_commit_info_t **com >>> apr_hash_t *commit_revprops; >>> int i; >>> >>> - /* Find the common root of all the source paths, and probe the wc. */ >>> + /* Find the common root of all the source paths */ >>> get_copy_pair_ancestors(copy_pairs, &top_src_path, NULL, NULL, pool); >>> - SVN_ERR(svn_wc__adm_probe_in_context(&adm_access, ctx->wc_ctx, >>> top_src_path, >>> - FALSE, -1, ctx->cancel_func, >>> - ctx->cancel_baton, pool)); >>> - >>> - /* The commit process uses absolute paths, so we need to open the access >>> - baton using absolute paths, and so we really need to use absolute >>> - paths everywhere. */ >>> + >>> + /* Do we need to lock the working copy? 1.6 didn't take a write >>> + lock, but what happens if the working copy changes during the copy >>> + operation? */ >> >> I'd switch this to a ### comment saying "we should lock the working >> copy to prevent changes while we perform the copy to the repository." >> >> But when we do that... aren't we starting a commit? and doesn't the >> commit lock the working copy? > > No, it calls the lower level function svn_client__do_commit that does > no locking. I think I'll change it to take locks, assuming that doing > so doesn't cause regression tests failures. I don't suppose anybody > relies on wc-to-repo copy "working" when the wc is already locked :)
Sounds good. Again, I would suggest the call_with_write_lock() function. I would like to eventually remove the acquire/release variants, as they are more prone to leaving locks around. Cheers, -g
