> [mailto:
e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
> Sent: Wednesday, November 12, 2008 11:03 AM
> To: E4 Project developer mailing list
> Subject: RE: [e4-dev] Using cvs import in the
> repository/CommonBuildInfrastructure
>
> Hi Paul,
>
> As I have mentioned before, I think the E4 CM Story needs
> some careful consideration before jumping rith into doing
> stuff.
>
> 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:
>
> cd ${local_e4_resource_workspace}
> export REPO=:pserver:anonymous@xxxxxxxxxxxxxxx:/cvsroot/eclipse
> export MOD=org.eclipse.core.resources
> cvs -d $REPO rdiff -d ${date_last_sync} $MOD > diffs.new
> patch -p0 < diffs.new
> ## review the patch
> cvs commit -m "resynch 3.5"
>
> Basically, we can re-sync as often as we want based on
> timestamp rdiff and it'll work nicely AS LONG AS THERE
> ARE NO STRUCTURAL CHANGES (moved/renamed/split files).
> In fact, this approach is not so much different than what
> cvs import does but it's manual, leveraging the fact that
> we have CVS and thus diffs for the "3rd party sources",
> and not using a branch; you could also see it as a manual
> merge operation for what advanced systems like git or
> mercurial or Clearcase can do automatically. Likewise,
> we may be backporting some features at times. Because I
> assume that the Streams will remain fairly close to each
> other, I hope that this will work with not too much overhead.
>
> In other words, please do *not* convert the resources plugins
> into using cvs import since we'd be losing our history that
> way. We deliberately decide to use this simple manual cvs-
> based approach since we don't expect many merge problems.
>
> For the UI / IDE work, it looks like you're in a different
> position since more work is going on in 3.5 land. In other
> words, you'll want to merge/re-base/re-sync much more often,
> and you may have structural changes. Having looked at this
> a bit more closely, I wouldn't recommend cvs import for this
> since I don't think it's going to pay you much. The import
> will bring 3.5 stream into a branch in e4; but you'll still
> have to manually merge the branch after that:
> cvs update -jThem:yesterday -jThem theirproj
> and this merge can (and will) create conflicts just like
> the manual apply-patch we're doing for resources. The
> further your streams get apart, the more conflicts you'll
> have and the harder the merge will get each time.
>
> It really depends on how you envision your streams to evolve.
> But I think that if I were you, I'd explore systems that
> can help you perform the merge/re-synch process even if
> your streams get further apart. git and mercurial have
> been built exactly with this scenario in mind (multiple
> dev.streams, multiple branches, applying/merging patches).
> Those systems are able to track structural changes because
> they identify each revision based on a Hash of its contents,
> so they can find it after a move.
>
> I haven't used any of these systems before myself, so I
> don't think I can give much more advice here other than:
> invest a bit of time looking for something that will
> fit your needs. The merge tool is likely most critical.
> IP may be an issue if you want the repository to be public,
> see
>
https://bugs.eclipse.org/bugs/show_bug.cgi?id=249745#c11
>
> I have looked at this just very superficially, but one
> idea that might work for improved branch support/merging
> is this:
>
> 1. Import e3.5 CVS into a local non-shared git repository
>
>
http://www.kernel.org/pub/software/scm/git/docs/gitcvs-migration.html
> Have a cronjob do this every night, such that you always
> have a local up-to-date git repo mirroring e3.5 CVS
>
> 2. Have a separate e4 git repository with git-cvsserver for
> e4 development through cvs:
>
http://www.kernel.org/pub/software/scm/git/docs/git-cvsserver.html
>
> 3. When you want to re-base / merge between e35 and e4, do
> this between the e35-gitrepo and the e4-gitrepo, by doing
> git push / git pull (likely commandline). In order to avoid
> IP problems with shared repositories, the direct git access
> should be limited to trusted people, only git-cvsserver
> access to be public.
>
> It might be possible to use mercurial or bazaar with a similar
> approach (i.e. internal repositories for merging/re-basing),
> but the advantages of git are that (a) it can remain hidden
> concealed behind a cvs emulation layer, and (b) merge strategies
> can be plugged in as needed.
>
> Cheers,
> --
> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> Target Management Project Lead, DSDP PMC Member
>
http://www.eclipse.org/dsdp/tm
>
>
>
> > -----Original Message-----
> > From:
e4-dev-bounces@xxxxxxxxxxx
> > [mailto:
e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Paul Webster
> > Sent: Tuesday, November 11, 2008 10:37 PM
> > To: e4-dev
> > Subject: [e4-dev] Using cvs import in the repository/Common
> > BuildInfrastructure
> >
> > It looks like we need to come up with a pattern for using
> Martin's cvs
> > import suggestion for managing 3.5 plugins that need to be
> edited but
> > not abandonned in the 4.0 world.
> >
> >
http://cvsbook.red-bean.com/cvsbook.html#Tracking%20Third-Part
> > y%20Sources%20(Vendor%20Branches)
> >
> > I know the resources plugins and org.eclipse.ui.ide are copied over,
> > but I'm not sure how we can continue to update them (if anybody has
> > ideas, please chime in :-)
> >
> > For example, org.eclipse.ui.ide needs another cut from HEAD as it
> > won't compile with the current I build. cvs import looks like it's
> > designed to take multiple cuts of the "3rd party software" but then
> > cvs import has to be used from the beginning (complete with vender
> > branches and vender tags :-)
> >
> > I can delete o.e.ui.ide and work with John Arthorne tomorrow to get
> > the pattern correct, but then I think that all of the other resource
> > plugins might have to be re-done. If that's a problem (i.e. work is
> > going to be lost), just let us know in the
e4-dev@xxxxxxxxxxx list.
> >
> > Common Build Infrastructure
> >
> > I've added a feature for the resources and tests plugins that are
> > currently in CVS, plus a o.e.e4.resources.releng plugin that I'm
> > setting up with the CBI. It will generate a zip for the resources
> > plugins that are platform independent, and a zip for the
> test feature
> > (I still have some problems with it looking for ${org.eclipse.test}
> > even though it's not supposed to be running the tests).
> >
> > The short term goal is to be able to create an update site that can
> > install the resources plugins, the swt tools (like flex dev
> env), and
> > the ui.model+emf+moz+js independently on a current 3.5 I build.
> >
> > Hopefully once we get the infrastructure in place, we'll be able to
> > start generating official builds.
> >
> > If you have any questions or comments, plase post them to the
> >
e4-dev@xxxxxxxxxxx mailing list.
> >
> > Later,
> > PW
> >
> > --
> > Paul Webster
> > Hi floor. Make me a sammich! - GIR
> > _______________________________________________
> > e4-dev mailing list
> >
e4-dev@xxxxxxxxxxx
> >
https://dev.eclipse.org/mailman/listinfo/e4-dev
> >
> _______________________________________________
> e4-dev mailing list
>
e4-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/e4-dev
>
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
