[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [e4-dev] Using cvs import in the repository/CommonBuildInfrastructure
- From: "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
- Date: Wed, 12 Nov 2008 17:01:17 +0100
- Delivered-to: firstname.lastname@example.org
- Thread-index: AclEzJU8kycKai5jRzaignHFwIbOeAAEo9gw
- Thread-topic: [e4-dev] Using cvs import in the repository/CommonBuildInfrastructure
If you need something NOW, you might be able to simply get
started with what you have in the e4 incubator CVS already
now, and keep using it for a while.
If I understand the git story correctly from what Andrey
has said, the following scenario should be possible at
any time you're ready, in order to move the plain CVS
story (with 2 separate repositories) forward into advanced
re-base + merge capabilities:
1.) git cvsimport e35-cvs --> e35-git
2.) git cvsimport e4-cvs --> e4-git
3.) git init e4-merged-git
git pull e35-git --> e4-merged-git
git pull e4-git --> e4-merged-git
4.) make e4-merged-git available as cvsserver for CBI.
In other words, convert each cvs repo into a git repo,
from which you can pull in a coordinated way. Not
being able to branch/tag in the e4-merged-git via CVS
should not be an issue for the CBI.
How does that sound?
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
> -----Original Message-----
> From: e4-dev-bounces@xxxxxxxxxxx
> [mailto:e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Paul Webster
> Sent: Wednesday, November 12, 2008 2:42 PM
> To: E4 Project developer mailing list
> Subject: Re: [e4-dev] Using cvs import in the
> OK, Martin's made a good case for not using cvs import at this stage
> :-) I won't be making any of those kinds of changes to the
> org.eclipse.e4.resources plugins.
> On Wed, Nov 12, 2008 at 5:02 AM, Oberhuber, Martin
> <Martin.Oberhuber@xxxxxxxxxxxxx> wrote:
> > Hi Paul,
> > As I have mentioned before, I think the E4 CM Story needs
> > some careful consideration before jumping rith into doing
> > stuff.
> I'm not sure I agree ... even if this is throw away, we still need
> regular builds now. There are 2 parts to what I'm working on:
> 1) How can our code be initially organized and deployed (i.e. how can
> PDE Automated Build build us something useful)? This work has to be
> done and is independent of SCM.
> I'll be refining my "targets" as we go this week and next week, but my
> goals for the moment are:
> org.eclipse.e4.resources: We should be able to produce an update site
> that would allow us to download the resources plugins into a 3.5 I
> org.eclipse.e4.ui: We should be able to produce an update site that
> would allow us to download the ui plugins + required software (EMF and
> Orbit plugins). At first, it will be fine to simply update a 3.5 I
> build with the ui plugins.
> org.eclipse.e4.swt; We should be able to produce an update site that
> would install some of the SWT developer tools (flex) into a 3.5 I
> 2) How do we get our tagged builds built and published on the
> eclipse.org web site? Right now that's based on the CBI and the work
> done in
> This is where there will be a lot more investigation and grunt work on
> our part. CBI's main usecase doesn't involve building products,
> amongst other things. I'll be taking my questions about how CBI can
> help us get going to the dash-dev@xxxxxxxxxxx mailing list.
> This is also where (assuming the foundation supported git) that we
> could investigate other repositories.
> > For the resources work, we are in the lucky position that
> > not much is going on in the 3.5 Stream. That's why we decided
> > to just copy a snapshot of the 3.5 CVS Repo and work from
> > there -- this gives us the advantage of having complete
> > History even when working in e4 land. For synching up the
> > 3.5 and e4 Streams, we'll likely just be using diff/patch:
> > that is, when some "interesting" stuff has been added to
> > the 3.5 Stream, create an incremental diff from it based
> > on the timestamp since the last re-synch, then, apply this
> > as a patch to the e4 Stream:
> As an aside, org.eclipse.e4.resources needs to re-sync their copy of
> org.eclipse.ui.ide since it won't compile.
> Paul Webster
> Hi floor. Make me a sammich! - GIR
> e4-dev mailing list