Slowly I Turn

[billroper]

I'm now doing a massive check in to ClearCase of all my changes. This will take hours to complete.

ClearCase has already managed to lose track of one file that was moved between directories as part of the process. I've readded it to source control, but the history is gone.

Because, you know, losing history is what source control is all about.

Update: Ok, I couldn't check the file in, but I was able to undo the checkout. That seems to have fixed things so my buddy sitting closer to the ClearCase Server could check out and check in the version of the file I sent him. *gleep*

Comments

[whl.livejournal.com]

Well, at least the per-seat licensing costs so much you aren't likely to switch.

[rono-60103.livejournal.com]

That is why I've often maintained the revision control idea of "check in early and often." Of course being able to do that depends highly on how your system is set up -- and I suspect that any system can be set up to encourage or discourage that practice depending on the way it is used.

For ClearCase I don't think I ever kept directories checked out any longer than I had to just to make sure that any files didn't get lost.

FWIW, if you go back to the previous revision of the directory where the file was moved from, the file and its history should be there. Now I don't know, or at least don't recall, any magic way of recovering it to recreate the move, sorry.

[mroblivious.livejournal.com]

I don't think so, not if you did a "ct mv". It's awfully weird that it lost the file altogether, I haven't seen that behavior before.

I just love how you can't ct mv files between vobs. Why on earth would anyone want to?

Feh.

[billroper]

The problem is that ClearCase seems to be confused as to whether the filename is all upper-case or all lower-case. Thus, the file now appears to be good and lost as far as ClearCase is concerned.

[billroper]

Given the distance that I sit from the ClearCase Server, file check out and check in is a slow and painful process. It takes a minute or so for each file. This is a powerful disincentive to checking in frequently.

[rono-60103.livejournal.com]

Ah-Ha! This is probably why I always heard that IBM (and probably Rational and Atria before them) recommended that you not put your servers in a different location from where your developers were (at least virtually) working. Of course a more cynical person might conclude that this was to sell more software, which it also accomplished (I think).

For my former employer, this meant that we had to, instead, maintain multi-site systems in Arlington Heights Ill., Lowell Mass., Madrid Spain, Cork Ireland and Bangalore India (but not all at once, I think we shut down Cork before we put Lowell on line). So, instead of painfully slow check in, we had to deal with problems when the multi-site syncs got out of whack. Ironically, this seemed to happen more between AH and Lowell than any of the overseas sites.

[billroper]

Yup. Unlike StarTeam, there's no compression on the link. And the exchanges appear to be very chatty, so the whole thing kills you when you have long ping times.

In theory, there's supposed to be a remote client that's better behaved. In my experience, it doesn't run appreciably faster and it managed to do something silly that required me to spend hours recreating the view within the first week I was using it.

That's a funny sort of "better behaved".