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 =
