It's all about the answers!

Ask a question

Remove function from a build.


Zoe Slattery (4011220) | asked Aug 15 '14, 5:05 a.m.
retagged Aug 22 '14, 12:46 p.m. by Jeff Care (1.0k3233)
We are migrating (mainly C) code from CMVC to RTC. We also have to migrate the department's processes which are at the moment very tied into CMVC.

One thing that we can do with CMVC is to exclude a track from a build if that track is thought to be causing a failure (in either system test, acceptance test or compilation/packaging). I think the closest equivalent in RTC would be to:

(a) Create a work space from the main stream
(b) Take out the change sets associated with a Work Item
(c) Take out any other change sets that are dependent on the ones that have been removed.
(d) Make a build from the work space

This seems to be fighting the design of RTC a bit. I wondered if anyone had encountered a similar issue and if so, what they did?


Accepted answer


permanent link
Jeff Care (1.0k3233) | answered Aug 22 '14, 12:39 p.m.
 Oh, how I miss CMVC (certain parts, anyway).

Unfortunately, as you've discovered, RTC has no concept of "reqing out" a track like you can do in CMVC. The method you identified will work, but as you said it's rather heavy handed. You can also "reverse" a changeset but the whole process is rather unintuitive as well.

RTC seems very much based on the idea that you just keep moving forward & deliver fixes - very much like you would see in the OSS world with CVS or SVN. Going "backwards" is possible but painful.
Zoe Slattery selected this answer as the correct answer

Comments
1
Zoe Slattery commented Aug 22 '14, 12:48 p.m.

Thanks Jeff :-)


That is exactly what we thought. I think this function is probably the only thing I'll miss about CMVC  - but it's quite a big deal when your development processes of the past 15 years or so are all built around the ability to yank stuff out at will.

We are in fact having to rewrite all of our development processes - maybe not such a bad thing -  I think it's probably better than writing complicated code to make RTC do what it wasn't designed for. 


Jeff Care commented Aug 22 '14, 1:09 p.m.

Personally I miss linked files the most. and track-control. and fine-grained file ACLs.


Geoffrey Clemm commented Aug 23 '14, 10:17 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I'm a big non-fan of linked files ... too much risk of breaking things unless you carefully test every change against every configuration that is "linked" to that common file.  Note that RTC does allow some kinds of access control to be defined on individual files.  I assume track control is largely what we're discussing in this thread?   Most of what can be done with track control can be handled by modeling a track as either an RTC stream or an RTC work item.

One other answer



permanent link
Geoffrey Clemm (29.1k23035) | answered Aug 23 '14, 10:14 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The approach I recommend for this use case is to use two RTC streams: one where all change sets are delivered (for continuous build), and the other to which changes are promoted (delivered) once they have been validated (ideally, validated by an automated verification suite, but possibly also requiring manual testing).  So rather than trying to remove change sets if they are proven to be bad, you instead promote change sets once they have been proven to be good.   There still can be cases where you want to drop a promoted change set from the validated, but you can use "reverse" for those, since it should be a relatively infrequent occurrence.
I've seen some customers which have multiple promotion levels, if they have multiple levels of testing performed by different teams or at different frequencies.

Your answer


Register or to post your answer.