Re: [mdt-ocl.dev] Moving to GIT

["Willink, Ed" <Ed.Willink@xxxxxxxxxxxxxxx>]

+1.

the rationale for "buckminster" prefix seems a bit thin, but no problem.

	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 16:34
> To: mdt-ocl.dev@xxxxxxxxxxx
> Subject: Re: [mdt-ocl.dev] Moving to GIT
> 
> +1.
> 
> Just some extra comments:
> 
> I'd like to definitely start core-tools split (do we finally 
> want to use 
> "core" as the term to do such a distinction?)
> 
> Concerning the jobs name. In principle the guidelines[1] for the job 
> name are:
> 
> - generally, name 
> is*build_system*-*project_name*-*version*-*qualifier*, 
> where*qualifier*could be "nightly", "release", or the Eclipse 
> version used
> 
> Some jobs doesn't include the build system name, however, I 
> like having 
> buckminster in the name because it helps to have our job in the 
> beginning of the hudson jobs list[2]
> The extra .0 neither is commonly used by other jobs nor necessary.
> I don't like the "nightly", "integration" qualifiers, since 
> we run every 
> kind of build type from the same job. I prefer what EMF does by using 
> "head" (not sure which is the GIT counterpart) and 
> "maintenance". So, my 
> proposal is the following job names_
> 
> buckminster-mdt-ocl-core-3.2-head
> buckminster-mdt-ocl-tools-3.2-head
> buckminster-mdt-ocl-3.1-maintenance
> 
> [1] 
> http://wiki.eclipse.org/Common_Build_Infrastructure/Getting_St
> arted/Build_In_Hudson
> 
> Best Regards,
> Adolfo
> 
> 
> El 31/05/2011 14:18, Willink, Ed escribió:
> > 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
> >
> > _______________________________________________
> > 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
> 
>