Inter-Project Merge

You can merge changes from one Code Co-op project to another under the following conditions:

Note: When a branch project is created, it inherits the history of the original project, which includes the branching point. However, when new members join the branch project, they don't get its full history. If a new member of a branch project wants to perform a merge with the original project, he or she has to import the history from the creator of the branch (or somebody else who has already imported it).

A merge is done in order to propagate changes from one project to another. It doesn't matter which project was the original one, and which was created as the branch—the merge can go either way.


Performing a Merge

The project from which you are propagating the changes is considered the source (branch); and the other project, the target (branch). The merging will propagate the changes made by a selected script (or, cumulatively, from all scripts since the branch point up to the selected script) in the source branch to the current version of the target branch. The merged changes will appear as file edits in the target branch, and they have to be checked in in that project.


Starting a Merge

At this point, Code Co-op performs a check to see if the target project shares history with the source project. If the test fails, either the projects are not releated or their histories don't reach far enough into the past.

Reviewing the Merge

When the projects are related—the common branching version is established— all the pre-branch scripts are greyed out. You can now select any post-branch script and do the file-by-file merge from within the details pane.

You will notice that each file has a Merge Status. Files will be marked as follows:

You can select individual files or all the files in the details pane and choose one of the following ways to perform the merge:

There are three merge modes available from a dropdown.

The easiest one to explain is the Cumulative merge. All changes to all files, from the branching point up to and including the selected script, are considered. Use this type if you want to update the target in one fell swoop.

A Common Ancestor merge is restricted to the files modified in the selected script, but it also goes back to the branching point. Use this merge if you want to update the target script-by-script. Start with the earliest script, do the ancestor merger, and check in the files in the target (maybe even using the same script comment as in the source). Repeat the same with the next script and so on. After each step, the next merge will will only involve the changes made by the consecutive script, since all previous changes have allready been propagated to the target. This way of merging will preserve the granularity of scripts.

Selective merge is probably the most natural to use. It only propagates changes made by the selected script. There is however an oddity that you'll have to accept.

The merger will show, in the left pane, the changes made by the selected source script. These changes will also appear in the merge-result pane. However, the right pane will also display some changes that are, in a way, spurious. They are the result of comparing the current target-branch version to the version just before the selected script in the source branch. These pseudo-changes will also appear in the result pane. It all works out just fine, but it requires some getting used to.

Once you have merged a file, its status will change to Merged. The Merged status is not persistent, it is kept only during the current session.

 

Accepting the Merge

After you have merged all the changes, go to the Check-in Area tab in the target project. You can review the changes once again by double-clicking on each file. Once you are satisfied, check-in the files to propogate the merge results to other project members.

See also: