- a conflict and ask the user what to do.
- What happens if an edited file in the origin has been moved in the target to a different subfolder? Should we try to apply the edit? I'd say yes. If the automerge succeeds, there's a good chance it is safe.
Bottom line, a source control tool should do all the operations which seem certain to be safe. And even then, the user needs a chance to review everything before the merge is committed to the repository.
Let's consider a simple example from Subversion. I created a folder called trunk, added a few files, and then branched it. Then I made three changes to the trunk:
- Deleted __init__.py
- Modified panel.py
- Added a file called anydbm.py
Then I asked Subversion to merge all changes between version 2 and 4 of my trunk into my branch:
Subversion correctly detected all three of my changes and applied them to my working copy of the branch.
3. Developer review
Best Practice: Review the Merge Before you Commit
After your source control tool has done whatever it can do, it's your turn to finish the job. Any conflicts need to be resolved. Make sure the code still builds. Run the unit tests to make sure everything still works. Use a diff tool to review the changes.
Merging branches should always take place in a working folder. Your source control tool should give you a chance to do these checks before you commit the final results of a merge branches operation.
The final step in a merge branches operation is a review by the developer. The developer is ultimately responsible, and is the only one smart enough to declare that the merge is correct. So we need to make sure that the developer is given final approval before we commit the results of our merge to the repository.
This is the developer's opportunity to take care of anything which could not be done automatically by the source control tool in step 2. For example, suppose the tree contains a file which is in a binary format that cannot be automatically merged, and that this file has been modified in both the origin and the target. In this case, the developer will need to construct a version of this file which correctly incorporates both changed versions.
The very last step of a merge branches operation is to commit the results to the repository. Simplistically, this is a commit like any other. Ideally, it is more. The difference is whether or not the source control tool supports "merge history."
The Benefits of Merge History
Merge history contains special historical information about all merge branch operations. Each time you do use the merge branches feature, it remembers what happened. This allows us to handle two cases with a bit more finesse:
Frequently you want to merge from the same origin to the same target multiple times. Let's suppose you have a sub-team working in a private branch. Every few weeks you want to merge from the branch into the trunk. When it comes time to select the changes to be merged over, you only want to select the changes that haven't already been merged before. Wouldn't it be nice if the source control tool would just remember this for you?
Merge history allows this and makes things more convenient. The workaround is simply to use a label to mark the point of your last merge.
Merge in Both Directions
A similar case happens when you have two branches and you sometimes want to merge back and forth