11.9 Checkout Determinism

DeltaV servers can be very different from each other. For example, some may allow a property like predecessor-set to be changed, which can allow the client to do a merge or prevent a fork. There's no way for a client to find out the server's policy on this. A server may even have different behavior for different resources in the same collection. With many DeltaV operations, it's hard or impossible for the client to predict what will happen.

Predicting Success

Clients often need to determine what actions will be allowed. It isn't enough for the client to try the operation to see if it fails. In a learnable and rich UI, the user is only presented with actions that are allowed. If a resource can't be checked out, the UI doesn't allow the user to initiate a checkout. To implement this kind of UI, the client must have some idea what actions will be allowed.

It's not necessary to be 100 percent accurate in this. Timing, edge cases, and errors can all make requests fail that otherwise would succeed. However, when policy forbids an action, the client should be able to find that out before trying it.

In particular, DeltaV doesn't make it easy for a client to know when to allow checkout and checkin. It's hard to know whether a resource is already checked out or whether a second checkout will be permitted. It's hard to know whether a checkin will be allowed and whether it will create a fork. Some answers can be determined in advance, and this section explains how to get as much of that information as possible.

11.9.1 How to Tell If a Checkout Exists

At this point, we have all the pieces to be able to tell if a VCR or any of its versions are checked out. Recall that if a VCR is checked out in place, the checked-out property appears on the source URL. If a checkout to a working resource exists, the version that was checked out has the checkout-set property with the URL of that working resource.

Thus, to find out if there are any checkouts relating to a resource, the client software must look for both kinds of checkouts. This is done most efficiently with a PROPFIND to the VCR to get the checked-out property and a REPORT method to the VCR to get the version-tree report including the checkout-set property.

If there is already a checkout relating to a resource, a user may choose not to check out that resource again, even if the server supports multiple simultaneous checkouts.

11.9.2 How to Tell If a Resource Can Be Checked Out

If a checkout exists, it may not be possible to do another CHECKOUT relating to the same version history. To find out if a resource can be checked out, the first step is to find out if it's already checked out. If it's not checked out, the client is probably able to check out the VCR or create a working resource (subject, of course, to access control). However, if the VCR or a working resource is already checked out, the client must look a little harder to see whether the server will allow another checkout.

Recall that the properties checkin-fork and checkout-fork are required on every version. These properties can be empty (action allowed) or take the value forbidden or discouraged. If checkout-fork is allowed, then a client may check out a version that already has a successor or is already checked out. If checkin-fork is allowed, the client may do a checkin that would create a fork.

Therefore, if a checkout exists, how can the client software find out if another checkout will be allowed, and if it is allowed, will it create a fork? (See Figure 11-12.)

Figure 11-12. Flowchart to decide whether to check out.

If the version is already checked out and forking on checkout is allowed but forking on checkin is forbidden, it's hard to know what to do. The client could create a second checkout of the same version, but only the first CHECKIN will be allowed normally. The second CHECKIN request will fail unless the client is allowed to edit the predecessor-set property to prevent the fork. Because the client can't know in advance which CHECKIN request will happen first and whether the predecessor-set is editable, the client can't predict whether the CHECKIN will be allowed.