Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Using cvs import in the repository/CommonBuildInfrastructure

Guys,

I'm a mere listener on this mailing list and unfortunately do not participate in the E4 effort, but I want to say the words of support for Git. Eclipse is stuck with CVS with all of its problems, and maybe E4 might be a good starting point to switch to a more advanced version control system.

Our company has been using Git for over a year, and the experience has been hugely positive. We're only using the command-line client, but I believe git-cvsserver should work well for those who cannot imagine typing something on the terminal on a daily basis. (We've were also using Mercurial before, and decided to switch to Git.)

We are also employing CVS -> git importing to use one of Eclipse projects, DLTK. (In our experience git-cvsimport has worked well with latest patches to cvsps applied; tailor did not work that well.)

If you find yourself exploring this approach and want to ask any questions, I'd be glad to answer.

On Wed, Nov 12, 2008 at 4:15 PM, Oberhuber, Martin <Martin.Oberhuber@xxxxxxxxxxxxx> wrote:
Hm,

reading a bit more about git-cvsserver, it looks like my
suggestion won't work well because of these LIMITATIONS:

  CVS clients cannot tag, branch or perform GIT merges.

  git-cvsserver maps GIT branches to CVS modules. This
  is very different from what most CVS users would expect
  since in CVS modules usually represent one or more
  directories.

Anyways, it looks like the hard facts with respect
to CM requirements are:

* e35 is in cvs and will remain in cvs.
* e4 repository needs to be separate from e35.
* two repositories need to be kept in sync
 (likely one-way-sync e35->e4).
* IP cleanliness may need to be considered for
 the e4 repository.

As another matter of fact, the experts for keeping
repositories in sync are the distributed cm systems
like git, mercurial, and bazaar. There are conversion
utilities from cvs available (like tailor, for
instance).

Unfortunately, with ESE coming up I don't have time
to explore this in more detail (and for e4 resources
I think we have a viable cvs only solution because
of low noise on e35)... I hope that you folks are
going to find the right thing.

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 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



--
Andrey.

Back to the top