Merging file versions

This is a feature of JBuilder Enterprise.

Comparable terms

Merging is only needed with optimistic, or concurrent-development, version control systems. Merging is how version control handles simultaneous changes to a file. Where a locking model of version control is used, only one user at a time makes changes, so there is no need for merging.

The merge function allows a version control system to collate the changes in the repository version and the changes in your workspace version, resulting in one version that incorporates all of the latest changes to a file. This is usually straightforward, but occasionally two users make changes to the same physical part of a file. This results in a merge conflict. Usually, when this happens, you can't check the file in until you have resolved the conflict.

Merge conflicts are purely textual. They happen when different users write changes into exactly the same space in the file. Version control systems are not able to recognize or handle conflicts in logic or usage, only physical changes to a text-based file. Other kinds of conflicts must be handled the same way they would be handled without version control.

Merging is done locally in order to protect the repository from possible conflicts. In the event of a conflict, the repository will not be updated with your changes until you resolve the conflict and check in the file.

This command is available from the Team menu for the file that's active in the content pane, and from the context menu in the project pane for all selected files.

This feature is supported in the CVS and ClearCase integrations.

For a glossary of generic version control terms, please see the Version handling glossary in "Comparing files and versions" in Building Applications with JBuilder.

CVS

CVS automatically performs a merge whenever you update a file. This means that, when you pull the repository version of the file into your workspace, CVS automatically rolls the two versions into one.

It's important to update before you commit a file, because it reduces the incidence of merge conflicts. If a file still has conflicts, updating it in JBuilder before committing it allows JBuilder to provide its conflict-handling mechanisms. JBuilder may not let you commit a file if you haven't updated it and there have been changes made to the repository version.

For more information on JBuilder's conflict-handling features, please see "Comparing files and versions"in Building Applications with JBuilder.

ClearCase

When Check In is used, JBuilder looks for updates to the selected files before checking them in. If any of the files have been changed by others, they are displayed in the Merging Files dialog box.

Click OK to allow JBuilder to merge the files. This is normally straightforward and results in a single version of each file that incorporates the revision on the repository with changes that you made locally. If there are differences in exactly the same physical part of the text, this will register as a conflict. JBuilder displays files with conflicts in another dialog box, and does not check them in. Unconflicting files will be checked in as usual.

Note: Conflicts must be resolved in ClearCase.

Click Cancel if you don't want to merge these files and risk a conflict. They will be removed from the list of files to be checked in this time. The other files will be checked in normally.