[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] Moving to GIT
|
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
