[platform-core-dev] Re: multi-stream/rollup support

[Thomas L Roche <tlroche@xxxxxxxxxx>]

Tom Roche Sun, 7 Nov 2004 14:27:08 -0500
>> One of the more painful problems for those of us working on
>> Rational Developer is "rolling up" commits to multiple streams at
>> certain points in the cycle ... like now. My team has just
>> (hopefully :-) completed v6, and now has several target streams:

>> 0 6.0.0.1: fixes for bugs that couldn't get fixed in v6

>> 1 6.0.1: some new function, more bug fixes

>> 2 HEAD: everything else (the open-field, blue-sky stream)

Note the heterogeneity of the target streams.

>> Unfortunately

>> * typically, commits to any lesser (i.e. lower-numbered, above)
>>   streams need to be "rolled up" (also committed) to the farther-out
>>   streams

>> * the platform does not easily accomodate working with multiple
>>   streams (unless I'm missing something, please lemme know if so)

>> Currently we maintain separate workspaces for each stream, and proceed
>> like the following, beginning in the {lowest-down, most immediate}
>> workspace:

>> 0 Note each changed file, commit to its stream.

>> 1 Propagate each changed file's changes to the corresponding file in
>>   the next-most-immediate workspace, if one exists. (AFAIK this must
>>   be done outside of eclipse, e.g. with emacs ediff-buffers.)

>> 2 Compile/test the patched workspace, and loop.

>> This is not too painful if a change involves only 1 file, however that
>> is rarely the case. In any case, It Would Be Nice if the workbench
>> could automate/ease more of the process (esp step 1), since this
>> situation occurs for much of the cycle (i.e. excepting only those
>> times when we are "locked down" onto one target stream/version).

Ed Warnicke Sun, 07 Nov 2004 19:39:04 -0600
> I *think* you are also describing a problem that I see frequently
> with needing to cross-commit a change to multiple development
> branches.

> A change may be done in branch A, but for various reasons also needs
> to be cross-commited to branches B,C, and D. At times this can be
> hugely non-trivial as A,B,C, and D may be enough different that
> there are some merge issues applying exactly the change set from A
> to B, C, or D.

> Is this the kind of thing you are refering to?

Yes. We maintain separate workspaces in order to contain the
uncertainty: after patching each workspace, we can compile and test in
it. I would like the platform to automate the patch process as much as
possible. Can you suggest additional or alternative function(s) toward
this end?