Our organization uses IBM ClearCase to manage its versioning controls (for better or worse). We've been working on our application for several years now, and a large number of activities have started to pile up as 'dependencies' for our existing build work.

My understanding from reading the PDF on Dependencies from IBM is that these dependencies are a 'natural' part of maintaining artifacts left by old activities. To quote the PDF:

In actuality, dependencies are created on purpose to avoid the possible destruction of data. 

While this seems reasonable, in some cases destruction of data is exactly what we want - a change activity has become obsolete, and we do not want it included in the build - or at the very least, we do not want it included when it would functionally change the class object we're trying to update.

This literature also suggests that the activity might include a dependency if two activities include a change in the same element, despite also saying that the final activity delivery should be based on the latest version earlier on the same page.

My question then is - should I be concerned if an activity has a large number of Dependency activities, that those activities might introduce changes we've purposely avoided or overwritten changes that are not desired for this application? Or is it safe to include dependency activities, because the end result will be a version of the class that is based on the most recent change to that class?

  • Or is it safe to include dependency activities, because the end result will be a version of the class that is based on the most recent change to that class? -- Any other arrangement in a versioning system would make no sense at all. If ClearCase doesn't work that way, you need to either figure out how to make it work that way or find another tool. Commented Mar 6, 2017 at 17:07
  • @RobertHarvey Unfortunately, the page 5 diagram and subsequent Page 6 explanation of said diagram from the link above both make it very clear that ClearCase does actually behave this way. And unfortunately, we won't be able to switch tools for several months, and have to work with what we've got.
    – Zibbobz
    Commented Mar 6, 2017 at 17:12
  • If you make a change such as the one you described, is that change reflected in the released code? Commented Mar 6, 2017 at 17:15
  • @RobertHarvey Unfortunately, it's difficult to figure out if it is or not. The number of changes we've got going in combined with the number of dependencies each one has (bordering on 20 or so for each one) make it difficult to figure out how each delivery will affect the application before committing ourselves to the deployment.
    – Zibbobz
    Commented Mar 6, 2017 at 17:17
  • 1
    You need to run some tests to determine what the actual behavior is. You might also want to contact IBM for some guidance. Commented Mar 6, 2017 at 17:20

1 Answer 1


The root problem here is that you are accumulating technical debt by using the knife without sharpening it when it is needed.

When you detect that your tools are slow, faulty or obsolete the best moment to fix or substitute them is immediately.

Otherwise the more you advance the slower you get.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.