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

[Thomas L Roche <tlroche@xxxxxxxxxx>]

Tom Roche 11/08/2004 11:27 AM
>> We maintain separate workspaces in order to contain the
>> uncertainty: after patching each workspace, we can compile and test
>> in it.

To clarify:

My group works on (to a first approximation) the same set of projects
(which happen to be plugins, but for discussion call them A, B, C) and
the same {streams, set of versions} (call them 1, 2, 3). Accordingly,
we will create workspaces like

/workspaces/foo containing projects A-C all of version 1
/workspaces/bar containing projects A-C all of version 2
/workspaces/baz containing projects A-C all of version 3

>> 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?
 
Ed Warnicke Mon, 08 Nov 2004 11:32:46 -0600
> We use task branches to all work (pulled from other integration
> branches). When a task is completed it's changes are commited back
> to the integration branch. If we need to cross-commit, a task branch
> is pulled against each additional branch to which we need to
> cross-commit (ie, a new project is created)

Hmm ... so IIUC in your case projects have no "ongoing identity": they
are merely version/snapshots of the larger codebase. (Or do I not UC?)

> and the patch is applied. Then each of these new task branches is
> tested and finally commited to their parent integration branch.

> Auto patching would be great. But I've also been thinking thoughts
> about 'dependent' workspaces. In the example above, each of the
> workspaces created just to receive a cross-commiting patch is
> 'dependent' on the projects in which the work was originally done.

That feels straightforward in my case, since

* each workspace contains the same set of projects

* each project in each workspace has the same version

> It would be nice to be able to see that dependency, and to in some
> fashion roll-up the dependent projects so that a developer could
> focus on the top level tasks they are performing without swimming in
> a see of pending cross-commit projects.

> Thoughts?

That sounds cool: user could declare that s/he wants to associate n
dependent <project|workspace>, then later fire some action to
propagate the changes in one to the others. Propagation UI could be
like existing refactoring UI: the platform would try to merge, and
user would have the option to approve, reject, or optionally twiddle a
bit before approving.

> Also, with Eclipse generally (AFAIK) working over one workspace at a
> time, how is cross workspace autopatching going to work?

Well, Eclipse already has some awareness of multiple workspaces (for
File>Switch workspace). Optimally that could be expanded. But
workspaces are in the filesystem (as Workspace Launcher knows), so a
minimal solution would be to enable patching an arbitrary file from a
file in the workspace.

However I'm deafened by the silence from the platform-core folks :-)
Does this sound like something youse would like to work on? Should we
create an RFE in bugzilla?