Compare and Merge Versions

This article details you how to compare and merge versions.
cahscm101
This article details you how to compare and merge versions.
2
Merging Versions
You resolve branching conflicts in
CA Harvest SCM
through merge processes. Merge processes let you view changes made to two different versions of an item, combine changes, and discard changes.
You typically accomplish merges in two stages. You can merge versions in the same project or across projects.
  • Merging a branch version, created by the Concurrent Update mode of check-out, to the project trunk requires the concurrent merge process.
  • Merging across projects requires use of the cross project merge process.
  • The interactive merge process is the second stage required for both types of merges. You can also use the interactive merge process as a single step for merging branch versions for a specific item.
External Compare or Merge Tools
The External Compare/Merge Tools Preferences dialog lets you specify an external compare/merge tool to use for file comparison and merging. You must enter command line arguments required to launch the selected external tool. You cannot perform a merge of versions that involves path, name, or status conflicts by using external merge tools. Use the default merge tool to resolve these conflicts.
The selected external compare and merge tool must be installed on your computer before you can use it. Additionally, the path to the selected tool must be listed in the Windows PATH environment variable.
CA Harvest SCM
supports the following external difference/merge tools, some of which permit three-way merge:
  • Araxis Merge Professional Edition -- Two-way compare, two-way merge, three-way merge
  • Beyond Compare -- Two-way compare, two-way merge, three-way merge
  • Diff Doc -- Two-way compare
  • Guiffy -- Two-way compare, two-way merge, three-way merge
  • WinMerge -- Two-way compare, two-way merge
For operating system support and version information about the listed external tools, see the
Release Information
.
The default tool is Default, which refers to the
CA Harvest SCM
interactive merge process. The Command Lines fields are disabled when Default is selected and you do not need to specify command line information to start the interactive merge process.
Default Command Line Settings
Default command lines for supported external tools are provided in the list of external tools that follows. All external tools require file names to be specified on the command line.
The following parameters define only file names and not complete file paths:
  • $(File1), $(File2)
    Defines files displayed in the left and right panes of the comparison tool.
  • $(TrunkFile), $(BranchFile), $(ResultsFile)
    Defines files displayed in the left and right panes of the merge tool and the results file for two-way and three-way merge.
  • $(AncestorFile)
    Defines common ancestor file for three-way merge only.
  • $(Version1), $(Version2)
    Defines the path to the files displayed in the left and right panes of the compare tool.
Some external tools require full path names and file names to be specified on the command line. For this case, the following corresponding parameters are defined:
$(FilePath1), $(FilePath2), $(TrunkFilePath), $(BranchFilePath), $(AncestorFilePath), $(ResultsFilePath)
Default commands for external tools are defined in the following list; the tools differ with regard to which parameters need to be replaced in command syntax:
For help with additional parameters you can set for a tool, see the help for that tool.
  • Araxis Merge Professional Default Command Lines
    Use the following compare or merge commands for the Araxis tool.
    The compare command has the following format:
    Compare.exe /wait /max /2 $(File1) $(File2)
    The two-way merge command has the following format:
    Compare.exe /wait /max /2 $(TrunkFile) $(BranchFile) $(ResultsFile)
    The three-way merge command has the following format:
    Compare.exe /wait /max /3 /a3 $(TrunkFile) $(BranchFile) $(AncestorFile) $(ResultsFile)
    • /a
      number
      Specifies which file in a sequence of files on the command line is the common ancestor file.
      The ancestor file displays in the center of the Merge screen.
      For example, in the following command /a3 specifies that the third file listed is the ancestor:
      Compare.exe /wait /3 /a3 $(TrunkFile) $(BranchFile) $(AncestorFile) $(ResultsFile)
      For example, in the following command /a1 specifies that the first file listed is the ancestor:
      Compare.exe /wait /3 /a1 $(AncestorFile) $(TrunkFile) $(BranchFile) $(ResultsFile)
    The two-way compare command from WorkArea has the following format:
    Compare.exe /wait /max /2 $(File1) $(File2) /title1:$(Version1) /title2:$(Version2)
    The three-way compare command from WorkArea has the following format:
    Compare.exe /wait /max /3 /a3 $(File1) $(File2) $(AncestorFile) /title1:$(Version1) /title2:$(Version2) /title3:$(Version3)
  • Beyond Compare Default Command Lines
    The compare command has the following format:
    BComp.exe /readonly $(File1) $(File2) /title1=$(Version1) /title2=$(Version2)
    • /readonly
      Specifies that editing the files is not allowed.
    • /title1
      Specifies a text version of the first file name without the path; file name(version) displays in the compare pane.
    • /title2
      Specifies a text version of the second file name without the path; file name(version) displays in the compare pane.
    The two-way merge command has the following format:
    BComp.exe /rightreadonly $(TrunkFile) $(BranchFile) /mergeoutput=$(ResultsFile) /title1=$(TrunkFile) /title2=$(BranchFile)
    The /rightreadonly option enables editing only in the trunk pane.
    The three-way merge command has the following format:
    BComp.exe $(TrunkFile) $(BranchFile) $(AncestorFile) $(ResultsFile)
    The two-way compare command from WorkArea has the following format:
    BComp.exe /rightreadonly $(File1) $(File2) /title1=$(Version1) /title2=$(Version2)
    The three-way compare command from WorkArea has the following format:
    BComp.exe /rightreadonly $(File1) $(File2)  $(AncestorFile) $(File1) /title1=$(Version1) /title2=$(Version2) /title3=$(Version3)
     
  • Diff Doc Default Command Lines
    Diff Doc can compare Microsoft Word documents (.doc or .rtf) with formatting intact. Merging is not supported. Diff Doc requires full path and file names to be entered in the command line.
    The compare command has the following format:
    DiffDoc.exe /m$(FilePath1) /s$(FilePath2)
    The /m option lets you specify the original file. The /s option lets you specify the modified file.
  • Guiffy Default Command Lines
    The compare command has the following format:
    Guiffy.exe -gm $(File1) $(File2)
    • - gm
      Suppresses file merge (compare only).
    The two-way merge command has the following format:
    Guiffy.exe -m $(TrunkFile) $(BranchFile) $(ResultsFile)
    • - m
      Specifies two-way merge.
    The three-way merge command has the following format:
    Guiffy.exe -s $(TrunkFile) $(BranchFile) $(AncestorFile) $(ResultsFile)
    • - s
      Specifies three-way merge.
    The two-way compare command from WorkArea has the following format:
    Guiffy.exe -m $(File1) $(File2) $(File1) -h1$(Version1) -h2$(Version2)
    The three-way compare command from WorkArea has the following format:
    Guiffy.exe -s $(File1) $(File2)  $(AncestorFile) $(File1) -h1$(Version1) -h2$(Version2) -hm(Merge_Result)
    • -h1
      Represents the header for the first file.
    • -h2
      Represents the header for the second file.
    • -hm
      Represents the header for the merged file.
  • WinMerge Default Command Lines
    The compare command has the following format:
    Winmergeu.exe $(File1) $(File2) /dl $(File1) /dr $(File2)
    • /dl
      Specifies a text description of the left-hand file without the path; file name (version) displays in the compare pane.
    • /dr
      Specifies a text description of the right-hand file without the path; file name (version) displays in the compare pane.
    The two-way merge command has the following format:
    Winmergeu.exe $(TrunkFile) $(BranchFile) $(ResultsFile) /dl $(TrunkFile) /dr $(BranchFile)
    WinMerge does not support three-way merge; the three-way Merge command line should be left empty.
    The two-way compare command from WorkArea has the following format:
    Winmergeu.exe $(File1) $(File2) /dl $(Version1) /dr $(Version2) /wr
    WinMerge does not support three-way compare for WorkArea.
Concurrent Merge Process
A version on a branch becomes part of the project trunk through the concurrent merge process. Until you execute this process, changes made on the branch exist only on the branch. After all items have been checked in to a branch, invoking the concurrent merge process for the package containing the changes causes the versions on the branch to be combined in a single version on the trunk. The new version created on the trunk is the latest in the view.
If more recent versions exist on the trunk than the version from which the branch was created, the version created by the concurrent merge is tagged as merged (M). If the version from which the branch was created is the latest version of the item on the trunk, the version created on the trunk by the concurrent merge has no tag.
CA Harvest SCM
does not support concurrent development of item paths; the concurrent merge process cannot create item path versions with the merged tag.
In the following diagram, the branch version 1.1.2 is concurrently merged with the project trunk. The version created by the concurrent merge becomes the latest on the view's trunk, version 3, and is tagged as merged.
Merge branch version 1.1.2 concurrently with the project trunk.
Merge branch version 1.1.2 concurrently with the project trunk.
In the preceding diagram, if version 2 did not exist on the project trunk, the concurrent merge process would have created a non-tagged version 2. Merged tags appear only when changes have been made on the trunk that could conflict with changes made on the branch. If version 1 is the latest version when the merge executes, no changes exist on the trunk to conflict with the branch versions, so a merged tag is unnecessary.
The merge-tagged version of an item must be resolved through the interactive merge process before another version of the same item can be concurrently merged to the project trunk. The check-out for update and cross project merge processes also cannot be successfully executed on an item for which a merge-tagged version exists; and packages which contain merge-tagged versions cannot be promoted or demoted to a state in a different view.
Merge a Branch Version to the Trunk
The concurrent merge process lets you merge a branch version to the trunk.
Follow these steps:
  1. Navigate to the package that has the branch version you want to merge.
  2. Right-click the package, and select
    concurrent merge
    process
    from the shortcut menu.
    The
    concurrent merge
    process
    dialog appears.
  3. Select Merge options:
    • Merge Conservatively
      Creates a merge-tagged version, regardless of the contents of the versions. An exception is when the branch version is the latest version in the view; in this case, it is closed and a normal version is created.
    • Merge Aggressively
      Creates a merge-tagged version only when conflicts are found. If no conflicts are found, the branch and trunk versions are merged to create a normal version.
      Note:
      A conflict occurs when a set of lines is modified in both the branch and the trunk; however, insertions and deletions are not conflicts.
    • Take Trunk Version
      Selects the trunk (target) to create the final version automatically, without comparing the contents of the versions. This option closes the branch, but does not create any versions on the trunk.
    • Take Branch Version
      Selects the branch (source) to create the final version automatically, without comparing the contents of the versions. This option creates a normal version on the trunk and closes the branch.
    The merge behavior is set.
  4. (Optional) Click the tabs to enter and view information:
    • Comment
      Specifies comments.
  5. Click OK.
    A version is created on the trunk and is the latest in the view.
Interactive Merge Process
The interactive merge
process lets you do the following:
  • Combine the changes made on unmerged branches with changes on the trunk.
  • Resolve a merge-tagged version after it is created by the concurrent merge or cross project merge process.
Binary files cannot be used with the interactive merge process. When this process executes, it first checks that the file consists entirely of printable characters (or control characters such as tab, carriage return, and line feed). If any area of the file contains binary data, the merge process does not execute and an error message displays.
The interactive merge process lets you perform a two-way or three-way merge:
  • Two-way merges let you see only the differences between two versions, without considering the common ancestor. You cannot see whether lines were changed, deleted, or added -- only that the lines are different.
  • Three-way merges let you see the differences between the two versions and the common ancestor. You can see whether lines were changed, deleted, or added.
If you want to check in a branch version and do not need to look at the differences between versions, make sure that it is the correct version, and click OK.
The following diagram shows a two-way merge process. The bold bi-directional arrow shows the comparison between the branch and trunk versions.
Two-way merge process
Two-way merge process
The following diagram shows a three-way merge process. The curved arrow shows the comparison between the branch and trunk versions, and the comparison between the common ancestor and the trunk and branch versions.
Three-way merge process
Three-way merge process
Merge Versions Interactively
The following procedure describes how to use the internal
CA Harvest SCM
interactive merge process and assumes that you want to resolve conflicts. If you selected Default for the merge tool preference, invoking interactive merge opens the interactive merge process. If you selected an external comparison tool for the merge tool preference, the external tool appears.
For more information about using the external tool to visually compare file versions, see that tool's documentation.
Follow these steps:
  1. Navigate to the item or merge-tagged version you want to resolve.
  2. Right-click the item or version, and select
    interactive merge
    from the shortcut menu.
    The
    interactive merge
    process dialog appears.
  3. Specify values to use for the merge; the versions for the Status, Name, and Path fields can be different.
    Note:
    • The two versions of the item being merged appear in the merge dialog with common blocks (lines identical in both versions) and conflict blocks. Conflict blocks are positioned side-by-side and are outlined.
      A
      conflict
      occurs when the same line or block of data is modified in both the branch and the trunk. Insertions and deletions are considered
      changes
      .
    • If the version being merged is a large file (according to your preferences set in the Version page), the Version Data field appears, which gives you an option to select the version data directly instead of opening the version content side by side to merge.
  4. Resolve conflicts by manually editing the left pane text or by clicking the following toolbar actions:
    • Copy all nonconflicting changes from right to left.
    • Copy current change from right to left.
    The left pane represents the branch version being merged; the right pane represents the latest trunk version.
  5. (Optional) Click Note to view information about the process.
    Click OK.
    The merge-tagged version is replaced by a new, Normal-tagged version as the latest in the project's trunk.
Compare a Workspace File with a Repository Version
You can compare a workspace file with a version in the repository to see how the file differs from the version. 
Follow these steps:
  1. Navigate the Navigator view tree to the file you want to compare.
  2. Right-click the file, and select Compare With Version in Repository from the shortcut menu. The Version Compare lists the file's versions.
  3. Double-click the version you want to use for the comparison. A Progress Information dialog appears, and the file and version appear in the Text Compare.
  4. Compare versions by navigating through the synchronized lines of code. You can locate lines that differ by clicking the bookmarks aligned vertically along the right side of the editor, or by clicking Select Next Change and Select Previous Change on the toolbar of the editor. You have compared the workspace file with the repository version.
You can also compare a file with a repository version by double-clicking the file in the Synchronizer view. 
The comparison works as follows:
  • If the file has an outgoing change, it is compared with the version from which the workspace item was originally populated.
  • If the file shows an incoming change, the workspace version is compared with the incoming repository version.
  • If the file shows a conflicting change status, the modified workspace version is compared with the incoming repository version.
The comparison pane on the left is the local workspace version and you can modify the left comparison pane to merge changes from the right pane or to make changes as necessary to reconcile the different versions. You can then save the left pane version.
Compare a Workspace File with the Latest Trunk Version
You can compare a workspace file with the latest trunk version in the repository to see how the file differs from the version.
Follow these steps:
  1. Navigate the workspace tree to the file you want to compare.
  2. Right-click the file, and select Compare With Latest Trunk Version from the shortcut menu. The Compare Editor view lists the file in the structure compare pane. 
  3. Double-click the file you want to use for the comparison. A Progress Information dialog appears, and the file and latest trunk version appear in the text compare pane of the Compare Editor. 
  4. Compare versions by navigating through the synchronized lines of text. You can locate lines that differ by clicking the bookmarks aligned vertically along the right side of the Editor, or by clicking Select Next Change and Select Previous Change on the toolbar of the editor.
You have compared the workspace file with the latest trunk version.
Compare Workspace Files with Each Other
You can compare a workspace file with one or two other workspace files to see how the files differ.
Follow these steps:
  1. Navigate the workspace tree, select two or three files that you want to compare, right-click, and select Compare With Each Other from the shortcut menu. If you selected two files, the comparison appears in the Compare editor and you can continue at Step 3. If you selected three files, the Select Common Ancestor dialog appears. 
  2. (Three-way comparison only) Select a file to use for the common ancestor. Click OK. The comparison appears in the Compare Editor. 
  3. Compare versions by navigating through the synchronized lines of code. You can locate lines that differ by clicking the bookmarks aligned vertically along the right side of the editor, or by clicking Select Next Change and Select Previous Change on the toolbar of the editor.
  4. (Optional) Type Ctrl+S to save your changes. The changes are saved.
You have compared the workspace file with another file.
Compare Package Versions with Their Trunk Versions
You can compare versions in a package with the versions on the trunk that they were derived from.
Follow these steps:
  1. Navigate the Workbench to the package that has the associated versions you want to compare.
  2. Right-click the package, and select Compare with Trunk from the shortcut menu.
    The Compare View tab displays the latest version of all the files in the package.
  3. Double-click the file that you want to compare.
    The differences in the selected version and the previous trunk version are highlighted in the compare window. Any further comparison uses the same compare window. While comparing the files from a previous trunk, the trunk versions in the present package are not considered.
    When you double-click an R-tagged file, the comparison uses the contents from the local file system to compare with the parent trunk in the
    CA Harvest SCM
    repository.
    • If one of the compared versions is a large file (according to your preferences set in the Version page), the Compare Version Attributes dialog opens.
    • If you have configured an external tool for compare, a separate instance of the tool opens for different versions of the package.
  4. Compare versions by navigating the synchronized lines.
  5. (Optional) Click the bookmarks aligned vertically along the right side of the Editor, or click the Select Next Change and Select Previous Change arrows to navigate the lines.
    The lines that differ are located, and you can compare them.
Compare a Branch Version with Its Parent Trunk Version
You can compare a branch version with its parent trunk version from the Explorer View tree or the Item History diagram.
To compare a branch version with its parent trunk version, right-click a branch version, and select Compare with Trunk from the shortcut menu.
The compare tool appears and displays the differences between the branch version and its parent trunk version. For R-tagged versions, the comparison uses the local content from the file system. This local content displays in the left pane to compare with the parent trunk, which displays in the right pane.
  • If one of the compared versions is a large file (according to your preferences set in the Version page), the Compare Version Attributes dialog opens.
  • If you configured an external comparison tool in Preferences, the external tool appears.
Compare Refactoring Changes
The Refactor Compare Viewer dialog lets you compare refactoring changes between local files or folders with their corresponding repository items or item paths. You can use the Synchronizer view to select conflicting changes either for local name and local path or repository name and repository path before committing the changes to the repository.
Follow these steps:
  1. In the Synchronizer view, right-click a refactored file or folder and select Compare Refactoring Changes from the shortcut menu. The Refactor Compare Viewer dialog appears. The left pane shows the local path of the file or folder and the right pane shows the repository path of the file or folder. Changes are identified by enclosing rectangles.
  2. (Optional) Use the copy-from-right-to-left toolbar button to get the path or name change from the repository to the local file or folder.
  3. (Optional) Click OK to make a local change. 
You have compared refactoring changes.
Compare Two Versions
You can compare any two versions of an item.
Follow these steps:
  1. Navigate the Workbench to the item that has versions you want to compare.
  2. Select two versions, right-click one of the versions, and select Compare from the shortcut menu.
    The compare tool appears and displays the differences between the two versions. The Compare tool uses the local path and the local file content for an R-tagged file.
  • If one of the compared versions is a large file (according to your preferences set in the Version page), the Compare Version Attributes dialog opens. 
  • The external compare tool appears if you invoked the compare from the Explorer tree and if you configured an external comparison tool in Preferences.
  • The default Eclipse compare/merge tool appears if you invoked the compare from the workspace.
  • The Compare tool uses the local file content and the local path from the file system for an R-tagged file.
Compare Versions or Files
You can compare two versions or files.
You can select two versions, right-click, and select Compare from the shortcut menu. This action shows a comparison and bypasses the dialog described in the following procedure.
Follow these steps:
  1. On the Workbench or the
    CA Harvest SCM
     plug-in toolbar, click Compare. 
    The Compare Versions or Files dialog appears.
  2. Populate the fields in the Compare Versions or Files dialog by doing one the following:
    • Dragging
      versions
      from the List View or the Explorer View to the fields. When you drag an R-tagged version, the comparison uses the local path. When you drag an N-tagged version, the comparison uses the repository path.
    • Using the browse buttons to locate and select local
      files
      .
    The versions or files for the comparison are selected.
  3. Click OK.
    The compare tool appears and displays the differences between the two versions. The internal
    CA Harvest SCM
    compare files process is read-only; changes cannot be made to the files.
    • If one of the compared versions is a large file (according to your preferences set in the Version page), the Compare Version Attributes dialog opens.
    • If you configured an external comparison tool in Preferences, the external tool appears. For some external tools, the compare and merge processes are combined. You can change the files, but 
      CA Harvest SCM
       does not save these changes.
Compare Version Attributes
When one of the two compared files is a large file, the Compare Version Attributes dialog opens. The large file is defined by you in the Version preference page.
This dialog displays the compared properties of the selected versions. The differential attributes are highlighted in Red color.
How to Show Package Information
You can view package information in the following ways:
  • Right-click a shared resource and select <SCM>, Compare or Replace With Version. 
The Compare list view shows package information in the Package State column. This column represents the state in which the package that contains the version resides.
  • Select the Incoming/Outgoing Mode View.
The compare label for the left and right panes include package state and name. The label format is in the form VersionName:VersionNumber (StateName:PackageName). The state name represents the state in which the package resides.
Compare Views
The compare view process lets you generate a report showing the differences between any two views, either snapshot or working, that exist in any project.
Follow these steps:
  1. Navigate the Explorer tree to the state associated with a view you want to compare.
  2. Right-click the state, and select Compare View from the shortcut menu.
    The
    compare view
    process
    dialog appears and the View fields show the view contexts when you invoked the dialog.
  3. Click the button next to the Path field to open the Repository Path Selection dialog.
    The dialog appears, and you can select a repository path and a different view. The Show Views with State Nodes option lets you show only views associated with states.
  4. Specify the items you want to show in the Compare View list by selecting one or more of the following options and clicking Compare.
    • Recursive
      Searches all paths beneath the current path and shows the item versions matching the other filtering criteria. This option works with the Show options. Typically, only items in the path specified in the View and Path fields and specified by the Results criteria are displayed in the dialog list.
    • Items only in View 1
      Specifies that all items in View 1 should be listed.
    • Items only in View 2
      Specifies that all items in View 2 should be listed.
    A list of items that match your criteria shows the items unique to one view or which have changes between the views. The dialog changes dynamically to let you change your options and refresh your comparison.
    • Common Items/Different Contents
      Specifies that all items that are common to View 1 and View 2 but have different contents should be listed.
    • Common Items/Identical Contents
      Specifies that all items that are common to View 1 and View 2 and have identical contents should be listed.
  5. (Optional) Select an item in the list, and click Difference.
    The Difference dialog appears and shows detailed, line-by-line differences between two text files.
  6. (Optional) Click Note to view information about the process.
  7. Click Close.
View Differences
The Difference dialog lets you see detailed, line-by-line differences between two text files. The versions being compared for differences are displayed in a read-only mode with common blocks (lines that are the same in both versions) and conflict blocks.
Follow these steps:
  1. Select an item in the Compare Views results list, and click Difference.
    The Difference dialog appears, displaying two panes that show the version names and their contexts:
    • left pane
      Contains the current project and view context when the Compare Views dialog was invoked.
    • right pane
      Contains the comparison view that was selected by the compare views process.
    The panes are synchronized to display the same conflict lines. Conflicting blocks are displayed side-by-side, and the portions of the item that are the same for each version are displayed across the width of the dialog. Shaded lines indicate conflicting text.
  2. View the conflicts by using the scrollbar or the conflict navigation toolbar buttons. Click Close.
Cross Project Merge Process
The cross project merge process lets you merge the changes made to items in one project with the changes made to the same items in another project. The merge creates versions in the target project that are the latest for each item on the trunk. For example, in release-oriented development, some developers work on a maintenance release such as Release 1.1, while others work on major functional changes for Release 2.0. Several items are updated in both projects and the groups must combine their changes to update the items in both projects.
Cross project merges use packages or snapshots. You select a destination package and one or more source packages or a snapshot for the merge. For the merge to be successful, the source packages cannot contain any reserved or merge-tagged versions. If you set the placement option to trunk only, the destination project cannot contain any reserved or merge-tagged versions of the items being merged; otherwise, a branch version for the incoming items is created.
A removed-tagged (D) item can be carried to the destination view if the item has already been removed in the destination; its new versions cannot be carried from the source. Renamed items in the source are renamed in the destination.
All items for the versions that are being merged must exist in one or more repositories shared by the two projects. If two projects do not share a repository, a cross project merge between the projects is not possible.
Branch versions are not eligible for a cross project merge. If the source package of a cross project merge contains branch versions, the merge process ignores those versions and executes a normal merge for trunk versions associated with that package. The presence of branch versions does not generate error messages in the merge process.
The versions created in the target project by the cross project merge are located on the trunk and are the latest on that project's trunk. Each version created as a result of the merge is tagged as merged (M) unless the trunk has not been changed, in which case conflicts do not occur and the source version is simply copied to the trunk of the destination project and not tagged. You can use the interactive merge process to resolve merge-tagged versions.
In the following example, a package in project Release 1.1 that contains version 3 of an item is cross project merged with a package in project Release 2.0, which contains one version of the item.
Example of cross project merge process
Example of cross project merge process
The new version 4 created in project Release 2.0 by the cross project merge is the latest on the project's trunk, and is tagged as merged (M). The destination package specified in the cross project merge process is associated with the new version, regardless of whether the package contained a previous version of the item.
Cross project merges can sometimes create versions of an item that did not previously exist in the destination project. For this to occur, the following conditions must be met:
  • The source and destination projects must share a repository.
  • The item for which versions are being merged must be a new item that was loaded or checked in to the shared repository. If the item was loaded into the repository, the destination project must have been associated with the repository before the item was loaded.
  • The item must exist in the source project. This rule is true in the following situations:
    • If the new item was checked in from the project.
    • If the project was associated with the repository after the item was loaded.
    • If the item was created in the project by a cross project merge.
When these conditions are met, the cross project merge process creates versions of the item in the destination project. If the source package of the merge contains only version 0 of the item, this version is copied to the destination project as version 0. If the source package contains a non-zero version, the merge creates a version 0, which is the same as the version being merged.
Cross project merges typically produce new, merge-tagged versions in the destination project; however, cross project merges can have different results. The resulting versions depend on the status of the versions in the source package and destination project.
Cross project merges can be performed using a snapshot. The merge rules for a snapshot are similar to that of the merge for a package. You select a destination package and a snapshot from the source project for the merge. By default, the versions that are modified (versions greater than the base versions) in the snapshot view are the only merged versions. When you want to merge the entire view including the base versions, select the Merge from Base Versions check box.
Merge-Tagged Version Restrictions
These restrictions apply to merge-tagged versions of items:
  • A merge-tagged version of an item must be resolved through the interactive merge process before another version of the same item can be cross project merged.
  • CA Harvest SCM
    does not support concurrent development of item paths; the cross project merge process never creates item path versions with the merged tag.
  • An item that has a merge-tagged version cannot be checked out for Update.
  • Packages that contain merge-tagged versions cannot be promoted or demoted to a state in a different view.
Cross Project Merge Options
The cross project merge options work as follows:
  • Merge Conservatively
    Creates a merge-tagged version, regardless of the contents of the versions. The process fails if the target package has an unmerged branched version of an item also in the source package.
  • Merge Aggressively
    Creates a merge-tagged version only when conflicts are found. If no conflicts are found, the branch and trunk versions are merged to create a normal version. Normal tags can only be created when the versions being compared are in the original baseline of both projects. If the versions were checked in after baselining, merge tags are created regardless of whether conflicts exist.
    A conflict occurs when a set of lines is modified in both the branch and the trunk; insertions and deletions are not conflicts.
  • Take Trunk Version
    Automatically selects the trunk (target) to create the final version without comparing the contents of the versions. This option creates a normal version on the trunk and closes the branch.
  • Take Branch Version
    Automatically selects the branch (source) to create the final version without comparing the contents of the versions. This option creates a normal version on the trunk and closes the branch.
The cross project merge placement options work as follows:
  • Branch Only
    Creates a version on the target branch. This lets you copy changes from the source project to the target project even if one or more target items are reserved for update in the main trunk. With this option, a branch is created to store the changes. The target package cannot be the same package that contains the items reserved for update on the main trunk.
  • Trunk Only
    Creates a version on the target trunk.
  • Trunk or Branch
    Creates a version on the target trunk or branch. This lets you copy changes from the source project to the target project even if one or more target items are reserved for update in the main trunk. If items are reserved for update on the trunk, a branch is created to store the changes only if the target package is not the same package that contains the items reserved for update. If items are not reserved for update on the trunk, the items are simply copied to the trunk.
Merge Versions Across Projects
The cross project merge process lets you merge the versions made to items in one project with the versions made for the same items in another project. The merge creates versions in the target project that are the latest for each item on the trunk. The merge process affects all items modified by a package, and you can merge multiple items simultaneously.
Follow these steps:
  1. Navigate to the package that is the target (destination) for the versions you want to merge.
  2. Right-click the package, and select
    cross project merge
    process
    from the shortcut menu.
    The
    cross project merge
    process
    dialog appears and your selected package is listed in the Target Package field.
  3. Complete the following fields as appropriate to select source versions and a destination package:
    • Project
      Specifies a source project.
    • Versions from Package
      Specifies versions from a package to use for the merge.
    • Versions from Snapshot
      Specifies versions from a snapshot to use for the merge.
      Note:
      By default, the versions that are modified (versions greater than the base versions) in the snapshot view are the only merged versions. When you want to merge the entire view including the base versions, select the Merge from Base Versions option. Removed items or paths are not removed in the target project, when you use this option.
    • State
      Specifies a source state.
    • Snapshot
      Specifies the snapshot to use as the version source.
    • Merge Base Versions also
      Merges the entire view including the base versions.
    • Target Package
    (Optional) Specifies the destination package for the merged versions. You can click the Package button and use the Select a Package dialog to select a different package.
  4. Select a merge option and a placement option from the Merge Options and Placement Options drop-down lists, respectively.
    • Merge Conservatively
      Creates a merge-tagged version, regardless of the contents of the versions. The process fails if the target package has an unmerged branched version of an item also in the source package.
    • Merge Aggressively
      Creates a merge-tagged version only when conflicts are found. If no conflicts are found, the branch and trunk versions are merged to create a normal version. Normal tags can only be created when the versions being compared are in the original baseline of both projects. If the versions were checked in after baselining, merge tags are created regardless of whether conflicts exist.
      A conflict occurs when a set of lines is modified in both the branch and the trunk; insertions and deletions are not conflicts.
    • Take Branch Version
      Automatically selects the branch (source) to create the final version without comparing the contents of the versions. This option creates a normal version on the trunk and closes the branch.
    • Take Trunk Version
      Automatically selects the trunk (target) to create the final version without comparing the contents of the versions. This option creates a normal version on the trunk and closes the branch.
    • Branch Only
      Creates a version on the target branch. This option lets you copy changes from the source project to the target project even if one or more target items are reserved for update in the main trunk. With this option, a branch is created to store the changes. The target package cannot be the same package that contains the items reserved for update on the main trunk.
    • Trunk Only
      Creates a version on the target trunk.
    • Trunk or Branch
      Creates a version on the target trunk or branch. This option lets you copy changes from the source project to the target project even if one or more target items are reserved for update in the main trunk. Consider the following:
      • When items are reserved for update on the trunk, a branch is created to store the changes only if the target package is not the same package that contains the items reserved for update.
      • When items are not reserved for update on the trunk, the items are simply copied to the trunk.
  5. (Optional) Click the tabs to enter and view information:
    • Comment
      Specifies comments.
  6. Click OK.
    The source package versions are merged to the target project.
Merge Versions From a Package
You can merge the changes modified by one or more packages to a target project. This option lets you merge multiple items simultaneously.
Follow these steps:
  1. Navigate the Workbench to the package that is the target (destination) for the versions you want to merge.
  2. Right-click the package, and select cross project merge process from the shortcut menu.
    The cross project merge process dialog appears and your selected package is listed in the Target Package field.
    Because process execution dialog names differ depending on the site,
    CA Harvest SCM
    documentation uses lowercase italic text to indicate the process dialog name by the process type.
  3. (Optional) Select a package from the Target Package drop-down list, or click the Package button and use the Select a Package dialog to select a package.
    The target package is selected.
  4. Use the Project drop-down list to specify a project from where you want to merge.
  5. Select the Versions from Packages option.
  6. Select the State from which you want to merge the changes and includes the source package. Click the plus sign (+) and add the packages that you want to merge to the target package. You can also select packages from different views.
    You can select multiple packages from different states. Do not select any state in the merge window and click the package select button; the packages of all states will be listed.
  7. Select a merge option and a placement option from the Merge Options and Placement Options drop-down lists, respectively.
  8. (Optional) Click the tabs to enter and view information:
    • Comment
      Specifies comments.
    • Note
      Provides notes about the process.
    Click OK.
    The source package versions are merged to the target project.
Merge Versions From a Snapshot
The cross project merge process lets you merge versions, including branch versions, from a specific snapshot to a target project.
When you create a snapshot, removed paths and items are not included in the snapshot view. Therefore, the changes for the remove operations in the source project are not included in the target project during the cross project merge process when you use the snapshot view option.
Follow these steps:
  1. Navigate the Workbench to the package that is the target (destination) for the versions you want to merge.
  2. Right-click the package, and select
    cross project merge process
    from the shortcut menu.
    The
    cross project merge process
    dialog appears and your selected package is listed in the Target Package field.
    Because process execution dialog names differ depending on the site,
    CA Harvest SCM
    documentation uses lowercase italic text to indicate the process dialog name by the process type.
  3. Complete the following fields as appropriate, including the following options:
    • Project
      Specifies a source project.
    • Versions from Snapshot
      Specifies versions from a snapshot to use for the merge.
      Note:
      By default, the versions that are modified (versions greater than the base versions) in the snapshot view are the only merged versions. When you want to merge the entire view including the base versions, select the Merge from Base Versions option. Removed items or paths are not removed in the target project, when you use this option.
    • Snapshot
      Specifies the snapshot to use as the version source.
    • Merge Base Versions also
      Merges the entire view including the base versions.
  4. Select a merge option and a placement option from the Merge Options and Placement Options drop-down lists, respectively.
  5. (Optional) Click the tabs to enter and view information:
    • Comment
      Specifies comments.
    • Note
      Provides notes about the process.
  6. Click OK.
    The versions that are modified (versions greater than the base versions) in the snapshot view are merged to the destination trunk. If you selected the Merge from Base Versions option, the entire view including the base versions is merged.
If one of the compared versions is a large file (according to your preferences set in the Version page), the Compare Version Attributes dialog opens. The external compare tool appears if you invoked the compare from the Explorer tree and if you configured an external comparison tool in Preferences.The default Eclipse compare/merge tool appears if you invoked the compare from the workspace.The Compare tool uses the local file content and the local path from the file system for an R-tagged file.