subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Subversion Wiki] Trivial Update of "RepetitiveResolvingOfTheSameRename" by PhilipMartin
Date Fri, 18 Nov 2011 12:28:10 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "RepetitiveResolvingOfTheSameRename" page has been changed by PhilipMartin:
http://wiki.apache.org/subversion/RepetitiveResolvingOfTheSameRename?action=diff&rev1=1&rev2=2

  
  We want the merge to automatically apply incoming changes to the moved items. These are
not uncommitted local moves, they are moves that have been committed to the repository. So
the solution is to identify moves in the repository history and then use those moves to adjust
the incoming merge differences so that they apply to the moved item.
  
- The first stage, identifying moves in the repository, is the subject of ongoing work (Record
moves in the database, extracting them from the log history, etc.).  Some work has also been
done on getting update to understand local, uncommitted moves, and this can probably be extended.
+ The first stage, identifying moves in the repository, is the subject of ongoing work (Record
moves in the database, extracting them from the log history, etc.).  The second stage involves
using the identified moves to avoid conflicts: some work has also been done on getting update
to understand local, uncommitted moves, and this can probably be extended.
  
  It is not clear how well automatic move identification will work in practice. Even if it
works well there will always be some moves that cannot be identified automatically, if only
because the user simply made the move using add/rm without any sort of copy. Another scenario
is splitting a file in two and later discarding one half.
  
  The idea here is to allow the user to resolve conflicts by telling Subversion "A moved to
B" and storing that information. This could happen before the merge, or during conflict resolution,
or at some other time.  The information gets stored in a property and committed so that it
is available for subsequent merges.  In this way the user only has to resolve the conflict
once and repeat merges don't conflict.
  
- This doesn't preclude automatic move identification. Initially we simply ask the user to
resolve all moves, but as automatic move identification starts to work it can bypass asking
(or perhaps suggest the answer).
+ This doesn't preclude automatic move identification. Initially we require the user to resolve
all moves, but as automatic move identification starts to work it can bypass asking (or perhaps
suggest the answer).
  
  = The Design =
  

Mime
View raw message