Search code examples
gitperformanceclearcasegit-checkout

Clearcase is so slow on checkin: how quickly checkin a large set of modified files?

I am used to use git/svn or cvs but know I need to work with clearcase.

My usual workflow consists of a daily 30 commits and about 5 checkout to an older revision.

With git, each commit is done in less than 5 seconds (It is slow because I need to write good comments) and every update from a previous revision takes about 10 seconds.

With ClearCase I noticed everything is different...

Each commit takes about 10 minutes (when I do refactoring I need to checkout a lot of files, more than 500 each time). And because I am working with embedded targets I have to work in this way : do some changes, commit, test on the plateform, debug, commit, go back to my first point.

  • To be able to go back in a previous revision with cc I have to create a label after each commit because setting a view to a specific date can be dangerous (server and local time are sometime different).

  • Then I have to apply the label to all my files.

  • It means about 30 labels per days.
  • If I want to go back to a previous revision I need to manually edit the config spec and reload my view.

It seems my usual workflow that I took from my experience with git or svn have to be different with clearcase.

And just for information here is the time I might spend everyday with git and cc:

git: 30*5 + 5*10 = 200s -> 3min cc: 30*600 + 5*800 = 22000s -> 6h

How would you speed up that process ?

Solution

  • The key difference between ClearCase and git is that it is a file-by-file VCS, meant to manage a large set of files with few modifications at a time.

    So if you have many modifications at once, the clearfsimport I suggested in your previous question is your best bet.

    But in general, that tool makes you re-think your workflow in order to:

    • split your code base into different set of files (setting a label on a small set of file is less time-consuming than setting it on all the file of a Vob).
    • manage different views in order to have one with the right config spec (or to launch an update in parallel)
    • merge regularly, on a dedicate set of file, to avoid having to merge too many files.

    That is why UCM was introduced: those "set of files" are called components, and putting a label is called "baseline".
    Plus in UCM you check-in your files in an "activity" (which plays the role of a commit).
    UCM can help keeping control on the management of those files.