On Sat, Nov 19, 2011 at 08:48:47PM +0200, Daniel Shahaf wrote:
> stsp_at_apache.org wrote on Sat, Nov 19, 2011 at 18:34:53 -0000:
> > Author: stsp
> > Date: Sat Nov 19 18:34:52 2011
> > New Revision: 1204035
> >
> > URL: http://svn.apache.org/viewvc?rev=1204035&view=rev
> > Log:
> > On the moves-scan-log branch, change the way data about server-side moves
> > is returned from the log history scanner.
> >
> > Before this change, a given sequence of moves which happened in
> > given revisions, such as:
> > rA: mv x->z
>
> To clarify, by 'mv' do you mean only sequences of the form:
>
> % svn log -qv -r N
> D foo
> A bar (copied from foo_at_r{N-1})
>
> or does the branch also handle other combinations of deletes and
> adds-with-copyfrom?
For now, given this change as part of rN:
D foo
A + bar (copied from foo_at_rX)
if ancestry can be traced back from foo_at_r{N-1} to foo_at_rX the heuristic
assumes it has found a move.
This avoids cases involving replacements from being flagged as a move:
r1:
A foo
r2:
D foo
r3:
A foo
r4:
D foo
A + bar (copied from foo_at_r1)
This will not be flagged as a move because foo_at_r3 and foo_at_r1 are not
ancestrally related.
Ideally, svn should also verify that the node was copied from at least the
last-changed revision before the delete happened. But it doesn't yet.
Recent discussion on IRC suggests that we should not rely on such
heuristics alone. When a tree conflict happens we should offer the
user the option to run the heuristic to obtain suggestions about
possible moves and resolutions. But the user should be free to tell
svn that bar was indeed a "move" from foo_at_r1, if that is how the user
wants the situation to be handled.
http://colabti.org/irclogger/irclogger_log/svn-dev?date=2011-11-17#l78
Received on 2011-11-19 20:19:06 CET