ansaurus

Question

Implementing mostly-atomic ClearCase commits

Answer 1

A:

Lock out all other users.

Do a backup of your server.

Do your commits.

If something goes horribly wrong, restore clearcase from backup.

Juan 2009-07-30 16:00:08

That's not acceptable in this environment, unfortunately. There are a lot of users, and they need continual access to the server(but not to the files that this will be touching).

Paul Nathan 2009-07-30 16:03:34

Personally, I hate clearcase and I am required to use it at work. That being said you need to either somehow be able to protect the files. Perhaps have them on an independent VOB from all the other files. Other than that, just backup the files with tar.

Juan 2009-07-30 16:20:40

Answer 2

A:

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

Ball 2009-07-30 16:17:34

The operations I use are largely simple: checkout, checkin, merge. I'm doing some "automagic" on the files. My desire is that I would have a "go" command, and if anything hinky happens in the middle of "go", "go" is stopped, and any changes are reverted so that the repository is left in the exact state it was prior to pressing "go".

Paul Nathan 2009-07-30 16:27:16

Answer 3

+4 A:

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)

VonC 2009-07-30 16:46:12

I'm not working in UCM.Question: If I'm reading the lock man page correctly, it stops checkouts/checkins? It says I cannot "# Modify the branch with checkout or checkin# Cancel a checkout using uncheckout " Is that specific to modifying the branch type itself, or the elements inside of it?

Paul Nathan 2009-07-30 16:52:19

What would you recommend for "Exceptional" circumstances. E.g., a copy is made during the interval while I am checking in. One person's suggested making a temp branch for the checkin, and then merging the two branches when all is done. (but that would be a merge of some 200 files, subject to the same issues).

Paul Nathan 2009-07-30 17:36:55

I would not recommend the temp branch as it would only postpone the problem. If you are locking the branch, no-one will copy over the files you are checking in, but of course some can access the files while they are not all checked-in. For them, an update of their view will be necessary.

VonC 2009-07-30 18:21:33

If they have a dynamic view, would a lock prevent the new versions showing up on the .../LATEST read?

Paul Nathan 2009-07-30 19:35:19

@Paul: nope, but trying to merge after checking in a temp branch would bring the same issue. A dynamic view is... dynamic. One solution would be to configure the client dynamic views not in myBranch/LATEST, but with mybranch/MYLATEST (a custom label you set before your atomic operation). Then, after the checkins, you MOVE the label MYLATEST and their dynamic view refresh themselves with the right content!

VonC 2009-07-30 20:06:48

@VonC. Thank you. :-) In this particular situation, there is a programmatic read of the files I am committing. So each "changeset" could have its own label, and the last operation would be to commit a file(say, "latest_valid_tag.txt"), which would have the changeset label. Then the reader could open the file, edit the config spec, and voila! they see the new versions.

Paul Nathan 2009-07-30 20:52:55

Answer 4

A:

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

Raj_pm 2010-10-19 22:44:30

ansaurus

tags:

views:

answers:

Implementing mostly-atomic ClearCase commits

related questions