7

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?

Laiv
  • 14,283
  • 1
  • 31
  • 69
Zibbobz
  • 1,522
  • 3
  • 13
  • 20
  • `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. – Robert Harvey Mar 06 '17 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 Mar 06 '17 at 17:12
  • If you make a change such as the one you described, is that change reflected in the released code? – Robert Harvey Mar 06 '17 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 Mar 06 '17 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. – Robert Harvey Mar 06 '17 at 17:20
  • @RobertHarvey I actually did do the latter - the link above is what I got from them, as well as this link: http://www-01.ibm.com/support/docview.wss?uid=swg21134482 which again says: "A dependency between activities can arise from the fact that they contain versions of the same element". Despite also saying, earlier in the same link, that the final activity version should be based on the *latest* change made. The information presented is a bit conflicting. – Zibbobz Mar 06 '17 at 17:27
  • [How Rational Clear Case Stole my Innocence and Nearly Ruined my Life](http://www.daedtech.com/how-rational-clear-case-stole-my-innocence-and-nearly-ruined-my-life/) – Robert Harvey Mar 06 '17 at 17:38
  • @RobertHarvey Believe me, you do not have to convince me that Rational Clear Case is a bad tool - I'm well aware of it now, but changing our control tools is completely out of my hands. – Zibbobz Mar 06 '17 at 18:24

1 Answers1

-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.

Alberto Salvia Novella
  • 117
  • 3