At key milestones in a development project, most views have changes that need to be propagated to another view, and sometimes to several views. When work is complete or reaches a suitable release point in an activity or sandbox view, it needs to be merged “up” to the parent view. When a bug is fixed in the main view, it may need to be propagated “down” to one or more release views. Sometimes a fix needs to be propagated “sideways”, from one release view to a sibling release view.
StarTeam provides you with a comprehensive cross-view change management tool for propagating discrete sets of changes from one view to another called View Compare/Merge.
View Compare/Merge is available through two application interfaces:
Compared to the use of process items, which tracks file changes within a view, View Compare/Merge is the preferred mechanism for propagating and tracking changes made across views, that is, from one view to another. A common use of View Compare/Merge is to propagate the changes in one view, as tracked by a process item, to another view.
View Compare/Merge uses a “session” concept, which is a specific view compare/merge operation that can be started, reviewed, adjusted, verified, and then committed. When you save a View Compare/Merge session, a change package object is created that contains all the changes and information about the changes made during that session. Except for locks, no data is modified in the StarTeam repository until the change package for that change session is committed, at which point all changes are applied at once to the target view.
Before a change package is committed, it can be saved and restored – potentially on a different machine. This allows one user to create the change package, then transfer it to a peer for review or to verify the change package before committing it.
The Cross-Platform Client interface allows user interaction with the entire View Compare/Merge process. The VCMUtility provides partial or complete automation of View Compare/Merge sessions, which can be helpful when a specific kind of session is performed repeatedly. View Compare/Merge sessions are interoperable between the two interfaces. For example, you can create and save a change View Compare/Merge session using the VCMUtility, then restore, review, and commit the session using the Cross-Platform Client. You can also apply the same changes in the committed change package to another view using a process called “Replay”.
Two StarTeam views are involved with every View Compare/Merge change session: a source view and a target view.
Every View Compare/Merge merge session has a specific merge type which controls the direction and semantics of the View Compare/Merge session.
There are a variety of reasons you might want to merge two views. A typical example would be code development in a software development company. If both maintenance and new development for a software product need to occur in parallel, a separate view is often created to store each set of source code files. If you fix some defects in the maintenance view, you may need to merge changes from that view into the new development view so that the next release of your product has the fixes.
You can compare and merge any two views if those views are in the same project. However, in general, you can merge only items that are related (that is, have a common ancestor), even though that ancestor may not be in either of the views you are comparing or merging. The exception to this is when files are matched by name.
View Compare/Merge allows you to do the following to reconcile differences between views:
View Compare/Merge always uses the source file (that is, the "merge from" file) from the last recorded merge as the common ancestor for performing three-way merges. When there is no recorded merge point, View Compare/Merge uses the most recent common ancestor. For example, if the item in the source view has the dot notation 1.9 and the item in the target view is 1.7.1.4, the most recent common ancestor is 1.7.
The View Compare/Merge Wizard has an available option called Auto-merge Files. When this option is selected in the wizard, View Compare/Merge automatically merges files without conflicting differences at the beginning of the View Compare/Merge session.
Auto-merge does a 3-way merge. The auto-merge examines the following in the merged file:
That means that it ignores lines that exist in both the child and ancestor, but not the root. It also ignores lines that exist in both the root and ancestor, but not the child. The former would be lines that have been deleted from the revision in the root view, and the latter would be lines that have been deleted from the revision in the child view.
It is possible that the merged file would be identical to the target file, even when the source and target files are different. For example:
Comparisons are made of an ancestor file foo.txt with the target (root view) foo.txt and with the source (child view) foo.txt The comparisons show that two lines in question were deleted when the ancestor revision moved to the root (target) revision, but were not deleted from the child (source) revision. Therefore these two lines were in both the ancestor and the child, but not in the root revision. In this case, the two lines in question were deleted from the root view revision. The auto-merge did not restore deleted lines.
You can perform a manual merge when you want to restore deleted lines, and you can perform an overwrite if you want the target (root) to exactly match the source (child). Even if the file is resolved with auto-merge, you can select overwrite or merge again manually.
Below are the most common views you will use in view comparisons and merges:
The main view is where new development eventually appears.
The activity view is a child view used for a set of related tasks such as the development of a new feature. This view generally ends when the activity is complete.
The release view is a child view used to maintain a specific version of an application or module. This view generally ends when the corresponding application or module is no longer supported.
The most common tasks associated with merging views are: