Re: svn commit: r923875 - /subversion/trunk/subversion/libsvn_client/copy.c

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

-- 
Philip