On Thu, Sep 03, 2009 at 02:56:50PM +0100, Bolstridge, Andrew wrote:
> I suppose renames is tricky if you want to keep history... but that
> shouldn't stop you from ignoring deletes, it's just the file addition
> that matters and has (sometimes) to be converted into a svn move
> instead, so you could skip deletes and solve half of all tree conflicts
> in 1 go :)
The deletes matter, they cannot be ignored.
In the current design, additions just tell you whether something was
added (without history, in which case there can be no move) or copied
(i.e. added with history, in which case there can be a move).
You only know if the copy was in fact a move if you know whether
there is a deleted counter part for the copied file.
So without looking at any deletions, you don't know if there is
a deleted counter part for a copied file somewhere which would
transform the copy into a move.
On top of that, we're not able to reliably match copied files which
were in fact moves to their deleted counter parts (as explained in my
original reply). So unfortunately, looking at deletions alone really
gives you all the information you will ever get from the current design
about moves. Unless you ask a human for help, because they know (or can
find out) whether they ran "svn move" or "svn copy", an important piece
of information which currently isn't represented inside the system.
Copies only conflict with existing items at the copy target location.
Moves, however, conflict if you move the same item to different
target locations. So they need to be treated differently.
Also note that the move may have happened in the history of the branch
you are merging to, rather than as a local change in the working copy
you are merging into. Just looking at the local state of the working
copy in isolation does not cover all cases.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2390692
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-03 16:50:03 CEST