12.4 MERGE

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 Rules

The 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 Merge

When 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.

graphics/12fig06.jpg

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:

  1. Client sends the MERGE request to a VCR, making it the merge target. The body of the request contains a source element with at least one merge source URL and the no-auto-merge element to tell the server not to attempt the merge automatically.

  2. Server checks out the VCR and adds the merge source URLs to the merge-set property. Server updates the predecessor-set property on the checked-out VCR to the target version, which is the merge target.

  3. Client combines the content of a merge source with the VCR contents and uses PUT to update the VCR with the combined content.

  4. Client uses PROPPATCH to remove the merged version's URL from the merge-set property and add it to the predecessor-set property. Repeat Steps 3 and 4 as necessary until merge-set is empty.

  5. Client may use CHECKIN to finish the operation.

  6. Server checks in the VCR and creates a new version with two predecessors indicated by the value of the predecessor-set property of the VCR.

12.4.3 Server-Managed Merge

The 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.

graphics/12fig07.jpg

Again, the details get a little more complicated:

  1. Client sends a MERGE request to a VCR. The request body contains the source element with the merge source URLs.

  2. The server checks out the VCR. If the server can combine any merge source into the merge target, it does so and adds the merge source URL to the auto-merge-set property. The content of the checked-out VCR is initialized to the result of the integration. If the server cannot combine a merge source (e.g., it encounters an unknown file type), it adds the merge source URL to the merge-set property to signal that the client must do this part.

  3. Client checks the value of the auto-merge-set property. If it contains URLs, the client should check that the contents of the VCR are consistent. If they are, the client should use PROPPATCH to move the URLs from the auto-merge-set to the predecessor-set.

  4. Client checks the value of the merge-set property. If it contains URLs, the client must do the merge for those source versions. Client uses PUT to update the VCR with the results of the client's merge and then uses PROPPATCH to move the merged URLs from the merge-set to the predecessor-set.

  5. When both merge-set and auto-merge-set are empty, client may CHECKIN.

  6. Server creates the new version with the content and predecessor-set of the VCR and checks in the VCR.

12.4.4 How Content Is Combined in Merges

DeltaV 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.

graphics/bomb_icon.jpg

DeltaV does not specify how dead properties are to be merged at all. If two dead properties on the two versions have the same name but different values, then it's impossible to know which value to choose or whether the values can be combined. In addition, DeltaV does not specify whether the server will merge dead properties when the server merges contents. If the client cares about dead properties, it's safer for the client to do the merge itself.

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 Workspaces

Merge 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.



WebDAV. Next Generation Collaborative Web Authoring
WebDAV. Next Generation Collaborative Web Authoring
ISBN: 130652083
EAN: N/A
Year: 2003
Pages: 146

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net