Hg rename issues
From Genunix
Contents |
Overview
Large projects in ON relied on Teamware's handling of renames. In particular, Teamware can apply content updates to renamed files, and it detects conflicting renames (i.e., the parent and child each moved a file to a different location). Rename support was in Mercurial 0.9.3, but light testing showed that it didn't always produce the behavior that Teamware users expect. Mercurial's rename handling has evolved since then and is now satisfactory for ON development (at least as of Mercurial 1.0).
This page documents the behavior that we expect for rename, as well as any discussion, random notes related to rename, etc.
Operations, Conflicts
Users can introduce two types of changes into a workspace: namespace changes and content changes. Namespace changes are
- create foo
- delete foo
- rename foo bar
(Copy is a special case of "create").
Mercurial includes a "mv -f foo bar" operation; that should be treated as
- delete bar
- mv foo bar
rather than
- update bar with the contents of foo
- delete foo
When updating from another workspace, any of these scenarios can be considered a conflict:
- content updates to the same file
- different namespace operations on the same file
- deletion of a file that has a content update
For rename, both the old and new names need to be looked at.
Expected Behavior
The handling of content conflicts is pretty well understood. Hand the parent, child, and ancestor to some code that resolves the conflict, perhaps with the user's help.
Creation of the same file in the parent and child, but with different contents, should be treated as a content conflict.
For namespace conflicts: in some cases (e.g., delete/rename), it may be necessary to prompt the user for a resolution. Note that a namespace conflict occurs when any two namespace operations (rename, create, delete) affect the same file, regardless of the type of the operation.
Rename/rename conflicts can be handled without prompting the user. If the parent did "rename P foo" and the child did "rename C foo", then the user will see this as a merge of the two versions of "foo".
If the parent did "rename foo P" and the child did "rename foo C", this can be treated as a rename plus the creation of a new file. Mercurial issues a warning that it "detected divergent renames of foo", and it gives the new names. This warning is useful for situations where only one rename should be carried forward (i.e., the other name should be deleted).
For delete/content conflicts: give the user the choice of whether to keep the modified file or delete it.
For non-conflicting operations (e.g., parent renames and child updates the contents), the user should end up with the new contents at the new name.
optimizations
For content updates, the SCM may detect the case where the file has the exact same contents in both workspaces, even though the changeset history is different. In that case, the SCM can optimize out any conflict handling, but that's not required.
Similarly, if the parent does "mv foo bar" and the child does "mv foo foo2; mv foo2 bar", the SCM can optimize out the conflict handling, but it's not required.
