We use a single transaction for moves within one db.
(and a transaction on both dbs at the same time for multi db)
Moving between working copies is fully supported since 1.0.
And requiring copy + delete in scenarios where you can move no breaks case
changes on case insensitive filesystems.
Just breaking valid user scenarios to record things locally that can’t be
recorded in the repository yet would be a -1 for me.
Local moves and metadata only moves without all kinds of unexpected error
scenarios are essential for integrations of Subversion tools in third party
tools.
*Not everybody uses ‘svn’ where move can be an interactive operation.*
You don’t expect a normal no-svn ‘mv’ to certainly require all kinds of
pre-conditions?
This is exactly the user scenario: users don’t expect errors halfway an
automatic refactoring that would leave their wc broken. If some moves
succeed and some fail and there isn’t a way to revert to the previous state
by moving things back, their tools break.
Bert
Sent from Windows Mail
*From:* Stefan Sperling <stsp_at_apache.org>
*Sent:* January 8, 2013 1:57 AM
*To:* Daniel Shahaf <d.s_at_daniel.shahaf.name>
*CC:* dev_at_subversion.apache.org
*Subject:* Re: 'svn mv' between disjoint wc's of disjoint subtrees
On Tue, Jan 08, 2013 at 02:28:34AM +0200, Daniel Shahaf wrote:
> Over at infra@ we ran into an issue where an 'svn mv' between two
> disjoint working copies --- each wc is of a different subtree of trunk
> --- became a mv without history. I couldn't reproduce that one with
> a 1.8-dev build. However, I ran into an issue with 'status' handling
> such moves:
>
> % $svnadmin create r
> % $svn mkdir -qmm file://$PWD/r/{foo,bar}
> % $svn co -q file://$PWD/r/foo
> % $svn co -q file://$PWD/r/bar
> % touch foo/iota; $svn add -q foo/iota; $svn ci -qmm foo/iota
> % $svn mv foo/iota bar/kappa
> A bar/kappa
> D foo/iota
> % $svn st -q foo bar
> D foo/iota
> > moved to foo/kappa
> A + bar/kappa
>
> This output appears to be wrong: the 'moved to' is wrong because the
> move destination is ^/bar/kappa, not ^/foo/kappa; and the "moved from"
> output is completely absent.
There is code to perform cross-wc.db copies, a remnant from the pre-1.7.0
times when wc-ng was still using multiple .svn directories.
I believe that is what makes the copy work though I'm not even sure we
intentionally support copies between disjoint working copies.
There also used to be checks for half-recorded moves, in which case the
status output would simply hide the fact that a delete/copy was part
of an incomplete move (i.e. where node A claims it was moved to B but B
has no back-pointer to A). With those checks in place you would just
see a copy + delete at the UI level.
I believe these checks were taken out, and the intent was to make it
impossible to record incomplete moves in the first place. Apparently
this particular case was overlooked when this was done. Or perhaps
this is still a TODO item. AFAIK a move still involves two wc.db
transactions, one for the delete and one for the copy, and I believe
there were plans to use a single transaction instead.
Off-hand I'm not quite sure what the correct behaviour should be.
Should the move just error out? We certainly cannot record it as a move
within the same wc.db. So we should probably require the user to run
'svn copy' and 'svn delete' instead, provided cross-WC copies are
supposed to be supported.
Received on 2013-01-08 10:01:16 CET