Recall from the previous chapter that you can do a single-file version-tree merge by changing the predecessor-set property of a checked-out working resource or VCR so that it points to two versions. When the new version is created at CHECKIN, the server keeps the predecessor-set value on the new version. Modifying the predecessor-set works great for single files, but with multiple files, there needs to be a way to coordinate the modification. The MERGE operation is specified in DeltaV to provide a convenient way to merge version trees from multiple files. Activities are used again to relate the files. In addition to merging the version trees, some DeltaV servers may be capable of merging the content of versions. If the server cannot merge content, then the client must do so and upload the contents of the new versions. Regardless of how the content is merged, the server is responsible for updating the version trees to show the merge. 12.4.1 Merge RulesThe MERGE operation checks out a VCR. Thus, the MERGE method takes the place of CHECKOUT when the client wants to begin a merge process. The client uses PUT, PROPPATCH, and finally CHECKIN to complete the process. Multiple files are involved if the client selects a number of VCRs in the same activity and checks each of them out with MERGE or CHECKOUT. During a merge, the merge-set property on the VCR acts like a "to-do list." It contains the list of versions that will be merged into the checked-out VCR. The predecessor-set property is the list of versions that have already been merged into the checked-out VCR. Either the server or the client may integrate the contents of the merge-set versions into the VCR. Whoever does the integration must move the version URL from the merge-set to the predecessor-set to show what has been accomplished. The next sections cover the details of what happens when the client performs the actual integration as well as when the server does the integration. 12.4.2 Client-Managed MergeWhen the client is 100-percent responsible for merging content, all the server does is a normal checkout, checkin, and then construct the version tree where the latest version has two predecessors. Figure 12-6 shows the two major steps of a client-managed merge. First, the MERGE method is used to check out the resource, replacing CHECKOUT. In this step, the client identifies both a merge source, which is a version, and a merge target, which is a VCR and its target version. Then the client must PUT the results of the integration between the merge source and merge target and PROPPATCH the merge-set and predecessor-set to show that it has done this. Finally, the client does a CHECKIN to complete the operation. Figure 12-6. Client-managed merge.The actual details of this process are slightly more complicated because the client can select multiple merge sources, which means that more than two branches are merged. Furthermore, the server does some of the property manipulation and verification. Here are the details:
12.4.3 Server-Managed MergeThe server-managed merge operation results in the same state and follows nearly the same process, but the server actually attempts to integrate the content of the merge sources with the merge target. The server gives the client/user a chance to verify that this was done correctly before checking in to commit the merge. As Figure 12-7 shows, when the server has integrated the content from a merge source during the MERGE operation, the URL of the merge source appears in the auto-merge-set property instead of the merge-set property. The auto-merge-set is a different kind of to-do list because it shows that the server has already done most of the work. The client can check each merged resource out and if it approves of the way the server did the integration, then it moves the URLs from the auto-merge-set to the predecessor-set. Figure 12-7. Server-managed merge.Again, the details get a little more complicated:
12.4.4 How Content Is Combined in MergesDeltaV does not specify how versions are to be combined by either the client or the server. Either client or server could use any algorithm. There is no provision for the server to include merge "conflict" information inside the body of the merge result, as CVS does when there are problems during the merge.
There is no way to find out in advance whether the server can actually integrate the contents of two versions. The client must be prepared to do the integration itself or cancel the checkout with an UNCHECKOUT operation if the server fails to merge the content. If the two versions being merged are on the same branch, then the later version is assumed to have the correct content, and the content from the later version is used. It's only when two versions are on different branches that the server or client is supposed to combine the content from both versions. 12.4.5 Merging, Activities, and WorkspacesMerge is quite useful in conjunction with activities and workspaces. The workspace may contain many changes to resources, the activity selects which of those changes to apply, and the merge feature helps apply those changes to another workspace. For example, the latest checked-in versions can be merged into a user's workspace so that the user has the latest content in his or her workspace. Since an activity can be checked in, a multifile atomic merge is done by checking out a number of files to the same activity, following the merge steps for each, and checking in the activity. |