On Tue, Mar 16, 2010 at 15:59, Philip Martin <philip.martin_at_wandisco.com> wrote:
> Greg Stein <gstein_at_gmail.com> writes:
>
>> On Tue, Mar 16, 2010 at 13:11, <philip_at_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
Received on 2010-03-16 22:16:44 CET