Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: typos; discuss a native way of handling the merge operation case


The conflict resolver scans the revision log to match up copies and deletions. See 'struct repos_move_info' and 'find_moves_in_revision()' in the file subversion/libsvn_client/conflicts.c. While this approach is not perfect (it does not corrrectly correctly handle deletions which happened inside copies, for instance) it is good enough to support users during conflict resolution in many use cases.


After A is moved to B in the repostory repository the user updates to the HEAD revision. The NODES table will now look as follows:


With changes from the trunk merged in.

This could be achieved by first reverting B, then moving A to B locally, and running the appropriate merges to get changes from trunk. However, the resolver has no way of knowing whether reverting B would destroy any local changes the user made to B after the merge. Ideally, such changes would be retained.