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 :) -- Philip
