views:

350

answers:

3

First of all: I am not an experienced ClearCase user, but I have lots of experience with other VCS and *nix command-line tools. WIth ClearCase, I use command-line tool ("cleartool") working in a Unix shell.

Problem: I have a small set of sources stored in the ClearCase. Once in a while a fresh .tgz with the same sources comes in and I have to update sources in the repository (process could not be changed so that other party will use ClearCase).

Now I do the following:

  1. Extract tgz into, say, "~/new_src"
  2. "ct setview ..." and cd to the place where the sources are (say, "/vobs/src")
  3. I compare the sources with "diff -Naurb . ~/new_src", examine diff's output and:
    1. Copy new files to the /vobs/src and do "cleartool mkelem" on them
    2. Checkout changed files, copy new sources over and commit them
    3. Do "cleartool mkdir" for new dirs and populate them

This process is slowly driving me crazy since in almost any other version control system I would just checkout the sources, copy new sources over, examine diffs, add new files and then commit the whole lot. Or, better yet, use tags/branches, though they are really not needed in this case - I need to have an up-to-date version of the sources in the repo, that's all.

I tried to checkout everything (using "cleartool co -nc find ."), copy new sources over, and commit changed files/add new files afterward. But this requires parsing of the "cleartool ls" output and is even messier.

I could miss something obvious, but several forays into Google tell me that I'm not. However, I'd like to hear it from ClearCase powerusers - is there any hope for clueless like me or not? :)

+2  A: 

I just want to be sure:

You do know about clearfsimport, right ?

Because after reading (may be too quickly) your question, that command may be what you are after...

That is what I thought... If you need more details, leave a comment to this answer. I will monitor those.

VonC
+1  A: 

I store a bunch of Perl modules in clearcase. But I just check in the tar.gz files, and have a script go and extract & install them (into the build tree) as part of the build process.

I'd probably lean towards the same idea with other languages as well - just have a step in the make files to extract the tarballs before the rest of the build continues. Makes it really easy to substitute new versions.

Tanktalus
A: 

If you use ClearCase UCM, so there is another approach to handle with 3rd party repository - use components (read-write or, usually, read-only).

BR, Tamir Gefen CM and ALM Consultant My blog: http://almmmm.wordpress.com