|
Size: 839
Comment:
|
Size: 1675
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| So there are probably a couple steps: | This is completed. |
| Line 3: | Line 3: |
| * get manifests * eliminate unchanged files * detect non-overlapped files (files not in both manifests) * put all "new" files in a "post" list. * go through each remaining file, attempt a merge. * if, while merging, we discover no common ancestor, we've hit a rename. Add the file to the post list. * once we have the post list (and have merged all non-renamed/copied files) we can find all the rename links * find ancestors across renames * do a second pass of 3-way merging * the big open question is do we always want to merge-across-copy or do we want to prompt? (my suspicion is always.) * there's a directory rename detection heuristic that's needed here as well and can be done during the overlap 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 |
This is completed.
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