RE: [eclipse-incubator-e4-dev] E4 Repository Setup

["Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>]

Hi all,

 

I like the idea that Antoine Toulme blogged about on Friday:
http://www.lunar-ocean.com/blog/how-git-can-help-eclipse/

 

Shared replicated repositories for individual E4 features seem

like a good idea to me -- at least up to a point where we want

to start integrating and creating combined builds.

 

From what I hear, git is weak on Windows, but Mercurial

might be an option:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=249745#c3

 

Cheers,

--

Martin Oberhuber, Senior Member of Technical Staff, Wind River

Target Management Project Lead, DSDP PMC Member

http://www.eclipse.org/dsdp/tm

 

 

---

From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
Sent: Monday, October 06, 2008 12:51 PM
To: E4 developer list
Subject: [eclipse-incubator-e4-dev] E4 Repository Setup

Hi all,

 

I got an action item from the Oct-2 call to notify the mailing list

about how "cvs import" can be used to track Eclipse 3.5 advances

in the E4 Repository.

 

It's basically described here:
http://cvsbook.red-bean.com/cvsbook.html#Tracking%20Third-Party%20Sources%20(Vendor%20Branches)

with the "cvs import" reference here:
http://cvsbook.red-bean.com/cvsbook.html#import

 

Now the question whether that's readily applicable to E4 is on a

different table. I think it depends a lot on how we envision the E4

work to move forward. To me, it currently looks like

• We want to seed the E4 Repository with E3.5
• We want to sync up at Milestones in order to adopt E3.5 bug fixes

CVS Import can do this for us (with merging automatically where possible), as long

as the structure doesn't deviate too much. In case we start moving things around,

it won't work any more (merge conflicts on each and every merge). So I propose

investing some thought NOW what we really want to achieve, before we start something

and get trapped in Merge Hell at some point. There are other alternatives possible.

 

I particularly think about Git, which I hear is quite good at Merging individual branches.

It has a cvsserver emulation, and Eclipse integration (Egit), and works very well on

Linux especially (the Windows port seems not yet as mature).

 

It looks like the various E4 technologies have slightly different requirements, if I'm not mistaken:

• SWT Browser Edition is developed in parallel to E3.5 and could likely also live in the E3.5 Repository -- which seems favorable to me, since having ONE Repository avoids merge issues right from the beginning
• For Resources, we might want to have one or multiple independent sandboxes just for Experiments, but will likely keep aligned with E3.5 enough to "release" things into the E3.5 Repository rather than keeping a separate E4 Repository around. Anyways, for Resources it seems not to be that much of a problem, since there's not so much change happening in the E3.5 Repository so there won't be too much to merge.
• For the UI Work, I just do not know what's appropriate.

My Proposal:

 

I would propose that we create Team Project Sets to pick up E3.5 stuff wherever

possible, and keep the E4 specific Repositories as small as possible, in order to

avoid merge issues. Create a Wiki Page ("Where to get the Source") to document

where the stuff is.

 

For now, it seems more important to have a technically sound Repository setup,

rather than one single Repository point of access for consumers. I'd propose

deferring Repository Changes wherever possible.

 

But I'd think that only the various component people can know what's best

for their stuff.

 

Those groups who already have some sources should start a "E4 Where to get

the Sources" Wiki page based on the current

   http://wiki.eclipse.org/E4/Running_the_demos

page.

 

Cheers,

--

Martin Oberhuber, Senior Member of Technical Staff, Wind River

Target Management Project Lead, DSDP PMC Member

http://www.eclipse.org/dsdp/tm

 

 

---

From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Boris Bokowski
Sent: Thursday, October 02, 2008 4:28 PM
To: E4 developer list
Subject: [eclipse-incubator-e4-dev] today's call

There are two topics for today that I know about. Feel free to bring up more.

Topic 1: Project provisioning - see http://www.eclipse.org/projects/project_provisioning_request.php
We need to make decisions on the following:

• Component structure
• Initial committers: Website update privileges (all?), Download server privileges (need to pick one or two)
• mailing list: move to e4-dev?
• Bugzilla: I am assuming we want a new "Product" called e4, but which components should we create? Suggestion: Core, UI, Resources

Topic 2: Pervasive themes - Martin sent an email to the list but we haven't discussed. Here is an excerpt from Martin's email:

I'm wondering what happened to the pervasive architectural themes
that were identified at the summit:

• Reducing Bloat
• Too Many Listeners
• Becoming More Asynchronous
• Eclipse Application Model

A lot of people signed up as being interested at the Summit, but who's
actually going to work on these items? And, given that these items are
pervasive across all components, how are we going to communicate 
about these things, discuss and share ideas?

Boris