[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [e4-dev] Using cvs import in the repository/Common BuildInfrastructure
|
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
>
