Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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:
with the "cvs import" reference here:
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
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member

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
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?


Back to the top