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
|