You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <da...@elego.de> on 2011/11/19 19:48:47 UTC
Re: svn commit: r1204035 - in
/subversion/branches/moves-scan-log/subversion: include/svn_wc.h
libsvn_client/update.c
stsp@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@r{N-1})
or does the branch also handle other combinations of deletes and
adds-with-copyfrom?
Re: svn commit: r1204035 - in
/subversion/branches/moves-scan-log/subversion: include/svn_wc.h
libsvn_client/update.c
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Nov 19, 2011 at 08:48:47PM +0200, Daniel Shahaf wrote:
> stsp@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@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@rX)
if ancestry can be traced back from foo@r{N-1} to foo@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@r1)
This will not be flagged as a move because foo@r3 and foo@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@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
Re: svn commit: r1204035 - in
/subversion/branches/moves-scan-log/subversion: include/svn_wc.h
libsvn_client/update.c
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Nov 19, 2011 at 08:48:47PM +0200, Daniel Shahaf wrote:
> stsp@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@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@rX)
if ancestry can be traced back from foo@r{N-1} to foo@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@r1)
This will not be flagged as a move because foo@r3 and foo@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@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