Question

We have a stream in ClearCase UCM. We create Views on this stream and fetch code for Build purpose. The total data copied is 10 GB. This is a huge codebase. I decided to investigate what makes it huge.

I found:

1) Multiple versions of Third Party applications are stored in
ClearCase

2) But only the latest Third Party applications are used by our
application

3) Lots of obsolete and redundant code is available

I proposed:

1) Removal of old versions of Third Party applications using rmname
(NOT rmelement) which will ensure the availability of element history

2) Removal of all redundant code

A total of 5 GB of obsolete data has been detected.

My Logic:

I think this is the best way to keep a stream of development clean. That is, the best way to organize a stream of development is to have the best, the cleanest and the leanest source code available.

Also, since all HISTORY will be available always in ClearCase, there is no need to panic about the deletion of elements.

I feel old, redundant and obsolete code and artifacts belong in HISTORY and not in the current stream of development.

Lastly, I feel ClearCase operations like making a baseline etc will take more time if we have bloat in the VOB. Since we do an incremental baseline for nightly builds, I do not think these obsolete items are baselined. But I feel all ClearCase operations are affected by bloat.

Is my LOGIC proper? Is my understanding of UCM ClearCase proper?
*Please let me know the best practice in such cases.*

People at my work place do not want to delete the obsolete files although 5 GB data is obsolete in the current stream.

Any help would be appreciated.

Answer 1

The best practice is actually separate from UCM in this case.
I too started by storing third-party binaries in ClearCase. It didn’t scale well and the Vob started to get bloated, and simply too large to be managed (ie backed up) easily.

I now prefer storing third-parties in an artifact repository like Nexus, and add a little maven script to my build process in order to download the right binaries at the right versions, as declared in a pom.xml file.

Note that to remove old versions of a binaries from a vob, rmelem or rmver are really not advisable (risk of hyperlink corruption), but I used to do:

cleartool rmver -data aLargeBinary@/main/.../branch/OldVersion

That would keep the version in ClearCase, but would remove the version content (ie the large binary itself): that allowed for the Vob to get much smaller.

---

That being said, I agree with your general policies (especially regarding redundant code)