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.