Re: 'svn mv' between disjoint wc's of disjoint subtrees

"Bert Huijben" <bert_at_qqmail.nl> writes:

>> -----Original Message-----
>> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
>> Philip Martin
>> Sent: dinsdag 8 januari 2013 11:23
>> To: Bert Huijben
>> Cc: Daniel Shahaf; Stefan Sperling; dev_at_subversion.apache.org
>> Subject: Re: 'svn mv' between disjoint wc's of disjoint subtrees
>>
>> Bert Huijben <bert_at_qqmail.nl> writes:
>>
>> > We use a single transaction for moves within one db.
>> > (and a transaction on both dbs at the same time for multi db)
>>
>> I think we use a single transaction for the copy half of the move, but
>> the whole move is two transactions with the delete half as the second
>> transaction. This is ugly because the move can be interrupted and then
>> a partial move is present in the database. I'd like to change:
>>
>> txn_to_copy
>> rename
>> txn_to_delete
>
> Did you read svn_wc_move() before replying this?
>
> <snip lock checks>
>
> SVN_ERR(copy_or_move(wc_ctx, src_abspath, dst_abspath,
> TRUE /* metadata_only */,
> TRUE /* is_move */,
> allow_mixed_revisions,
> cancel_func, cancel_baton,
> notify_func, notify_baton,
> scratch_pool));
> <snip comment>
>
> if (!metadata_only)
> SVN_ERR(svn_io_file_rename(src_abspath, dst_abspath, scratch_pool));
>
> <snip some conflict fixups that should have been part of the copy_or_move
> transaction>

Despite its name the function copy_or_move just does the copy half of
the move (marking the copy as moved-here) it doesn't do the delete half.
So when the function returns we have the new NODES rows for the copy but
we don't have the NODES rows for the delete. The NODES rows for the
delete are created by the call to svn_wc__delete_internal and they get
created in a separate transaction.

>> into
>>
>> txn_to_copy_and_delete
>> run_wq_to_rename
>>
>> so that the problem goes away. Fundamentally that can't work with
>> disjoint working copies. I think move between disjoint working copies
>> will have to degrade to copy+delete, otherwise something like:
>
> Ok, so you deliberately want to break TortoiseSVN and AnkhSVN?
>
> This is nothing about disjoint working copies, this is about using multiple
> working copies from the same repository. Something AnkhSVN and TortoiseSVN
> users do all the time.
>
>> svn mv wc1/A wc2/B
>> svn up wc1
>>
>> is going to have to update the disjoint wc2.
>
> And how are you going to handle
> $ svn mv wc1/A wc2/B
> $ mv wc2 wc3
> $ svn up wc1
>
> Look through the entire filesystem?

We can't handle it. That is my point. We can't easily make the update
affect the move destination so we fall back on the 1.7 behvaiour where
the update only affects the delete half and copy half remains an
unchanged copy.

> I don't think we can support moves between working copies, but that doesn't
> make it an option to break 'svn mv' and its atomic 1.7 behavior.

I'm proposing that a move between working copies should degrade into a
copy and delete so that move between working copies behaves as it does
in 1.7.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download