Implementing mostly-atomic ClearCase commits

Question

I have a project where I need to perform a number of operations on a dynamic view. If any of those operations fails, or some error comes up in the program, I need to be able to back out the commits.

The straightfoward way seems to be to simply put the commands into a queue and then, when my program finishes processing, execute the queue. However, I am concerned about some exceptional event interrupting the commits and causing an inconsistent dataset on the server.

Or, in other words, I'm looking for a way to create a svn-style 'changeset' in Clearcase dynamic views. The script language I'm using is Perl, if that matters.

Ideas?

Answer 1

The atomicity of operation in ClearCase being at the file-level, there is no strict equivalent of a svn changeset (i.e. a "revision").

The closest thing of a changeset in ClearCase is the notion of activity (in UCM), or a label set on a collection of files (a UCM Baseline is actually closer, since it represents labels you cannot move, on a pre-defined set of files -- UCM component --)

Now, UCM or not, I would recommend:

• locking the branch on which you will make checkins (that way, the vob is still accessible, and nobody is trying to add other versions on that particular branch during your "atomic" operation)
• do your checkins
• unlock the branch

In case of trouble, while the branch is still lock, you can 'ct rmver' the versions added. (Note: to use with care: a rmver can not be undone)

• Note1: if you are not working in UCM, you will have to record all checked-in versions in order to be able to rmver them

• Note2: when I said "lock the branch", I meant of course: "lock for everyone except you" (-nusers yourLogin). That way, only you can make checkins (that applies to all files in LATEST on the branch on which you are working (main or another).

---

The problem, with this approach, is what the clients (the other users with their dynamic views in LATEST on the branch) will see during your atomic transaction.
Since those are dynamic views, they will see the checked-in files while these files are checked-in, one by one. That may not be good, especially if there are 200 files and if the all process takes more than a minute.

One solution would be to have those client views set their config spec to the following:

element * .../myBranch/FREEZED_LATEST
element * .../myBranch/LATEST

If you are not doing atomic changeset commit, the label FREEZED_LATEST does not exist, and all the client views are displaying LATEST, as they should. Any checkin is immediatly seen by all.
But during your atomic commit, you could:

• first set a label FREEZED_LATEST on all the current files (currently in LATEST, that is)
  That means, all the clients will only see those specific versions during the atomic commit
• do your process (all the way, or roll back: either way, the branch is locked, and the config spec of the clients still shows the same "freezed" content)
• delete the label FREEZED_LATEST (all the clients go on seeing the new LATEST resulting from your atomic operation, and can make new versions with some checkouts of their own)

Answer 2

With v7.1.1 ClearCase supports atomic commits.You will be able to treat a set of files as one unit and check them in or rollback based on a given criteria.For more info , for more info see https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/index.jsp?topic=/com.ibm.rational.clearcase.relnotes.doc/topics/c_cc_relnotes_features.htm

Answer 3

Lock out all other users.

Do a backup of your server.

Do your commits.

If something goes horribly wrong, restore clearcase from backup.

Answer 4

I haven't used clearcase in years, so here are a few stray and naive thoughts.

Look ahead and determine if files are out of sync.

I would lock all the files you're about to check in before checking them in, and if you fail to lock one, abort the whole mess, with a useful message.

Can you "delete" a check in? Or revert, so HEAD looks at a previous version? Define your undo of a check in.

Can you make a temporary branch, check-in, then merge/rebase (my terminology is lose here). That way your rollback is to kill the branch. Though I remember coworkers cursing clearcase because of it's branching.

In general, queuing actions is great, but use the queue to identify potential problems before they occur. In addition, define your actions and their UNDO criteria, so if they want to do something that isn't pseudo-atomic, you can warn them, "This might get messy".