You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@gmail.com> on 2010/03/16 18:27:36 UTC
Re: svn commit: r923875 - /subversion/trunk/subversion/libsvn_client/copy.c
On Tue, Mar 16, 2010 at 13:11, <ph...@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?
>...
Cheers,
-g
Re: svn commit: r923875 - /subversion/trunk/subversion/libsvn_client/copy.c
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Mar 16, 2010 at 15:59, Philip Martin <ph...@wandisco.com> wrote:
> Greg Stein <gs...@gmail.com> writes:
>
>> On Tue, Mar 16, 2010 at 13:11, <ph...@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
Re: svn commit: r923875 - /subversion/trunk/subversion/libsvn_client/copy.c
Posted by Philip Martin <ph...@wandisco.com>.
Greg Stein <gs...@gmail.com> writes:
> On Tue, Mar 16, 2010 at 13:11, <ph...@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