[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] Moving to GIT
|
Hi Team
The releng issues seem minor and tractable within the slightly longer pre-M1
timescale,
so let's go for it. In practice, no commits after RC4, so Axel can practice
from RC4 to
release, and then go for it the following day.
If full history is migrateable, let's do it once. emf.ocl plugins too.
Features folders seems like a good idea.
We can sort out Hudson jobs later, initially one for Adolfo to do real
builds, then we can
see what else is helpful. ?? just "mdt-ocl-3.2.0-integration" ??
Regards
Ed
> -----Original Message-----
> From: mdt-ocl.dev-bounces@xxxxxxxxxxx
> [mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On Behalf Of Adolfo
> Sánchez-Barbudo Herrera
> Sent: 31 May 2011 14:01
> To: mdt-ocl.dev@xxxxxxxxxxx
> Subject: Re: [mdt-ocl.dev] Moving to GIT
>
> Ed, Axel
>
> I've not used GIT yet, so I can't give any point concerning the
> migration from CVS to GIT. I think that Axel's experience
> will be very
> helpful here...
>
> Concerning Buckminster / Hudson. I think that tasks are quite easy to
> achieve:
>
> 1. A change in the hudson job configuration so that the
> org.eclipse.ocl.releng.buckminster project is downloaded in the job's
> workspace using Git rather than CVS.
> 2. Some changes in the ocl.rmap file so that OCL sources are obtained
> via a Git Source Provider rather than the currently defined
> CVS Source
> Providers.
>
> BTW, In the new Git repository structure I'd consider
> creating a feature
> folders for the features. Currently, in our CVS the features and the
> plugins are all mixed in a plugins folder.
>
> Best Regards,
> Adolfol.
>
> El 30/05/2011 12:35, Axel Uhl escribió:
> > Hi all,
> >
> >> Axel: I think you volunteered to supervise the migration
> from CVS to GIT
> >> after the Indigo release.
> >>
> >> Axel: Have you had a chance to consider what might need to be done?
> >
> > I see two sorts of things that need to happen:
> >
> > - initial import: we have to make up our minds what we'd
> like to take
> > with us. I suggest to have the entire history of the OCL project
> > migrate from CVS to GIT. My understanding is that there is admin
> > support on eclipse.org side assisting us with such a first-time
> > migration.
> >
> > - adjusting releng; in particular the Hudson job needs to
> be aware of
> > the git repository and the branch to check out for
> building. I suggest
> > I have a meeting with our eGit committers at SAP to get their
> > recommendations. Perhaps we can afford to have more than one build
> > job, for different branches, given how easy and convenient it is on
> > git to branch/merge. According to my experience this can
> help avoiding
> > broken builds for the master branch. For example, if Ed want to try
> > some outrageously complicated refactoring for Pivot and
> still have the
> > luxury of a central build, Ed would do so on a git branch
> and happily
> > commit to that branch with Hudson building / testing that
> branch for
> > him. Re-basing on master, one more build, then merge into master is
> > then fairly easy.
> >
> > - commit and CQ procedures: we briefly discussed this at
> EclipseCon,
> > and I haven't received full clarification on this subject yet. I
> > assume that ideally we can manage to have only commits by
> registered
> > OCL committers in the commits that get pushed. I have to check the
> > details of pushing multiple commits at once. This is how we usually
> > work in our internal projects. Many committers doing many small
> > commits locally. When their stuff looks halfway reasonable
> they push a
> > whole series of commits to a branch that Hudson can build. If that
> > looks ok they merge it into the master branch. Not sure we
> can get to
> > something equivalent at Eclipse because someone mentioned that the
> > procedures would suggest single-commit-pushes only which I
> would find
> > somewhat unfortunate. Action item for me is to get clarification on
> > this until after Indigo.
> >
> >> I briefly tried to access the Xtext GIT repository without
> success (very
> >> brief, didn't read the guide).
> >> But it did appear that I needed to set up multiple levels of
> >> redirection.
> >>
> >> This might be good. Presumably I can set up my local
> repository on my
> >> network RAID redirecting to the
> >> Eclipse GIT. This could solve my laptop/tower workspace
> synchronisation
> >> difficulties.
> >
> > It most certainly will. You usually "git clone" some central
> > repository to a local git. You can clone this again to other
> > locations. Synchronizing between them happens by pushing / fetching
> > the commits.
> >
> >> Axel: How do we migrate CVS? or is GIT an upper level
> continuing to use
> >> CVS as its lower implementation?
> >
> > There is a git-cvsimport utility that I'm using regularly to
> > synchronize the OCL CVS into my local git and from there to github
> > where we have our FURCAS development with branches that
> test our OCL
> > contributions before we submit them to the Eclipse CVS.
> git-cvsimport
> > has its shortcomings in day-to-day use but should be fine for a
> > one-shot migration. For example, git-cvsimport is trying to
> group many
> > CVS file commits into larger git commits, based on timestamp and
> > commit log message. But that's guessing. And sometimes I
> experienced
> > that git-cvsimport loses some commits which can get really
> nasty. But
> > if we get eclipse.org's support in doing the one-time synch
> and have
> > all committers commit to git only afterwards, that shouldn't be a
> > problem. It means, however, that we should have releng more or less
> > prepared before we do this, or we'd have to rely on
> git-cvsimport to
> > do at least one more synch before we stop committing to CVS.
> >
> > And, no, git does not use CVS as an underlying impl. GIT
> has a binary
> > file-based repository underneath that has a structure
> fairly different
> > from that of CVS which---being based on RCS---has a
> file-by-file view.
> > GIT takes a commit-by-commit view where each commit holds
> the changes
> > to one or more files which can include renames/moves, deletions,
> > creations and so on. GIT commits also know their
> predecessor commits,
> > so all branch/merge activities are recorded in the commits, too.
> >
> > Best,
> > -- Axel
> > _______________________________________________
> > mdt-ocl.dev mailing list
> > mdt-ocl.dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
> >
>
> --
> Open Canarias, S.L.
> *Adolfo Sánchez-Barbudo Herrera*
> adolfosbh(at)opencanarias(dot)com
> <mailto:adolfosbh%28at%29opencanarias%28dot%29com>
> C/Elías Ramos González, 4, ofc. 304
> 38001 SANTA CRUZ DE TENERIFE
> Tel.: +34 922 240231
>
>
Please consider the environment before printing a hard copy of this
e-mail.
The information contained in this e-mail is confidential. It is intended
only for the stated addressee(s) and access to it by any other person is
unauthorised. If you are not an addressee, you must not disclose, copy,
circulate or in any other way use or rely on the information contained in
this e-mail. Such unauthorised use may be unlawful. If you have received
this e-mail in error, please inform us immediately on +44 (0)118 986 8601
and delete it and all copies from your system.
Thales Research and Technology (UK) Limited. A company registered in
England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne
Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number:
774298
Thales UK Limited. A company registered in England and Wales. Registered
Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone,
Weybridge, Surrey KT15 2NX. Registered Number: 868273
