Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

We are new to RTC and we would like to know the best way to structure our RTC project(s) and how to work on multiple releases simultaneously for a code base.

Questions
Tags
Users
Badges
Michael Whitner
(56●1●10●10) retagged
Dec 16 '13, 12:49 p.m.
Today we have an single code base in a CVS repository that contains multiple products.  We want to migrate this single code base into RTC but, we are unsure of the best approach for structuring one or more projects within RTC.

We would like to have distinct code bases but, each code base would have groups of developers working on different releases of the respective code base. These groups have different members, different goals, different delivery dates, but are working on the same respective code base.

We are new to RTC and we would like to know the best way to structure our RTC project(s) and how to work on multiple releases simultaneously for a code base.

0 votes

Comments
sam detweiler
Nov 20 '13, 10:28 a.m.
can u expand on this 'We would like to have distinct code bases but,' a little. release is an arbitrary word, which can mean lots of things..  in RTC this generally means some deliverable external to the development team. will the teams members overlap? this usually causes trouble and confusion cause RTC doesn't provide good ways of isolating time spent across multiple projects concurrently by the same people. are you going to use the planning and workitem components of RTC as well as the source?  this is pretty normal.. People (teams) doing work (workitems) over time (iterations) = Plan.

1 answer
8,815 views
0 votes

One answer

Permanent link
Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (30.1k●3●34●35) Nov 22 '13, 12:10 a.m.
For "distinct code bases", you probably should consider storing each code base in its own RTC component (assuming a "code base" maps naturally to a single file system tree).   Until you have a good reason to do otherwise, I would start with a single project area, and create a separate team area for each team.   Each team would have a stream (initially, just one stream per team... you can add more later if needed).  The code bases (components) being worked on by a given team would be added to that team's stream, giving each team its own configuration of that code base.

0 votes

Comments
Michael Whitner
Nov 22 '13, 8:14 a.m.
Thank you both for your responses! I do have an additional question for clarification in my own mind. Speaking with the product owner it is my understanding that within a team they could be working on different releases at the same time in the same component. Would that imply multiple streams within that component? I envision a “main" stream per component with the code imported from CVS as the baseline. Each release would create a “release” stream from the “main” stream that flows back into the “main” stream. Developers working on that particular “release” stream would create workspaces from the “release” stream that flow back into the release stream. When the “release” is compete and the product is delivered to the world, the changes on the “release” stream can then be accepted back to the “main” stream. Is this the proper way to perform simultaneous release development within a component?

sam detweiler
Nov 22 '13, 9:45 a.m.
let me see if I can reflect that back properly. you have a master codebase.  you fork the master for a release (may be multiple forks, 1/release)..  at some point you attempt to merge the forked changes back into the base. how do you support the releases? with changes to the forked code? for how long? who does the release maintenance, same development team? is the maint work combined with the new release development (dev r+2, maint r,r+1?) we had one product that had 1 component, a master stream, and a stream per customer (much customization).  SOME of the changes at the customer level also affected the master stream, so we would have to push those changesets into multiple streams. (change flow target) each new customer would branch from the master at that time. the child streams lived on forever in parallel.

Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Nov 23 '13, 2:32 p.m.
The only adjustment I'd make is to flow the changes from the release streams reasonably frequently to the main stream, and not wait until the release is complete.  In addition, rather than flowing all of the release streams to the main stream, I'd flow each of the release streams just to the next higher release stream, and then the highest release stream flows to the main stream.

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,143
× 1,210

Question asked: Nov 20 '13, 10:12 a.m.

Question was seen: 8,815 times

Last updated: Dec 16 '13, 12:49 p.m.

Confirmation Cancel Confirm