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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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%20Source
s%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
<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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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
<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
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
