[platform-core-dev] multi-stream/rollup support, was: Issues with large-

[Thomas L Roche <tlroche@xxxxxxxxxx>]

John Arthorne Fri, 5 Nov 2004 13:21:40 -0500
> This is a general call for those using Eclipse for large-scale
> development to let us know what the major problem areas are.

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)

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