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

[Michael Valenta <Michael_Valenta@xxxxxxxxxx>]

I'm not a Platform Core guy but I work
on the Team/CVS component. I think that Platform Core (more specifically
Platform Resources) would definitely need to play an enabling role here
if auto-patching accross dependant workspaces were to be a possibility
but I'm not sure that such a tool should live in the Eclipse Platform.
My reasoning is this. The funtionality that you are discussing is really
part of change management. From a Platform standpoint, it would be interesting
to know what the requirements on the Platform for such a tool would be
but  it seems like bug tracking systems and code repositories play
a role in how such a tool would work. I would go as far as to say that
the repository and bug tracking tool used by a team would affect how such
a mechanism would need to be implemented.

As a case in point, the Apply Patch
wizard which is shipped with the Eclipse Platform can be used to apply
patches of a particular form to any Eclipse project, folder or file. However,
I know of at least one repository provider that uses it's own mechanism
for patching so having the Apply Patch menu item in products that are shipped
by this vendor is confusing for the user. What you are discussing can be
viewed as an extension of Apply Patch (although it is really a generate
patch and apply somewhere else). If this were included in the Eclipse Platform,
it would exist in all products based on Eclipse and would thus potentially
interfere (at least by causing confusion) with similar mechanisms that
are provided by change management tools build on top of Eclipse.

So, I think it would be appropriate
to log a feature request against Platform Resources for funtionality that
would enable this type of tool (I suspect there is already a bug for workspace
switching) but I think the tools themselves would need to live elsewhere.
If you feel that a CVS specific tool of this kind would be useful then,
by all means, log a feature request against Platform CVS. If you are using
other repository tools, you may want to ping them to see what they think
as well.

Michael

Thomas L Roche <tlroche@xxxxxxxxxx>
Sent by: platform-core-dev-admin@xxxxxxxxxxx

09/11/2004 01:38 PM

Please respond to
platform-core-dev

To	platform-core-dev@xxxxxxxxxxx
cc
Subject	[platform-core-dev] Re: multi-stream/rollup support

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?

_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev