> [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@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/e4-dev