Differences between revisions 5 and 6
Revision 5 as of 2006-09-18 08:09:32
Size: 1462
Editor: mpm
Comment:
Revision 6 as of 2006-10-15 16:34:57
Size: 1719
Editor: mpm
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
This is mostly complete except for directory rename detection.
Line 8: Line 10:
The first can be addressed by a rename-aware ancestor algorithm placed in filectx and used by merge3. General outline: The first can be addressed by a rename-aware ancestor algorithm placed in filectx and used by merge3. (implemented)
Line 15: Line 17:
The second operates at the manifestmerge level. The second operates at the manifestmerge level. (implemented)
Line 21: Line 23:
 * use most recent ancestor data as fallback for unpaired files in manifest merging  * use this data for unpaired files when merging
Line 25: Line 27:
 * for each manifest, construct a list of dirs  * generate a list of directories for each manifest
 * scan the copy map, constructing a directory copy map
 * if a directory gets "copied" to two places, remove it from the map
 * remove entries in the directory copy map for all directories that still exist

This is mostly complete except for directory rename detection.

See CopyMergeCases for use cases.

The use cases indicate two different areas we need to handle renames:

  • merge on a file that has been renamed remotely and locally to the same file
  • files that have been copied/renamed on one side and possibly modified on the other

The first can be addressed by a rename-aware ancestor algorithm placed in filectx and used by merge3. (implemented)

  • create an ancestry graph spanning all the renames in question
  • find the roots of the graph
  • create a child graph and find the distance from the roots
  • visit each node searching for the common ancestor as in revlog.ancestor()

The second operates at the manifestmerge level. (implemented)

  • find the ancestor changeset - no renames before this point are interesting
  • find all files that aren't paired (local, remote)
  • find all historic copies/renames for all unpaired files back to ancestor changeset
  • find most recent ancestors between (unpaired local, remote) and (local, unpaired remote)
  • use this data for unpaired files when merging

Some thoughts on directory rename detection:

  • generate a list of directories for each manifest
  • scan the copy map, constructing a directory copy map
  • if a directory gets "copied" to two places, remove it from the map
  • remove entries in the directory copy map for all directories that still exist
  • construct lists of unpaired dirs (local, remote)
  • if a rename above moves a file from an unpaired dir elsewhere, it's probably a directory rename
  • again, use this data as a fallback for dealing with unpaired files in manifest merging


CategoryNewFeatures

RenamePlan (last edited 2012-10-25 21:19:32 by mpm)