Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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_Started/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
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231

Back to the top