> -----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:
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 */,
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
> 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?
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.
Received on 2013-01-08 12:21:44 CET