After a discussion among board members, developers and users present at
the 2009 emc fest (as well as previous discussions on the #emc-devel irc
channel), the board of directors has voted unanimously to transition to
the git revision control system.
Since it was created as a sourceforge project nearly 9 years ago, emc
development has used the CVS version control system, which at the time
was very widely used and reasonably state-of-the-art.
In the last few years, use of distributed revision control systems like
git has become widespread, because these systems offer very important
benefits over cvs. These are some of the benefits we have identified:
Working does not require a continuous net connection. Only pulling
and pushing changes to the public repository requires a connection.
Diff, log, commit, etc. are all done without the net. (major)
Local history makes all operations faster (minor)
Change sets instead of per-file history makes it easier to find
and understand a change. (major)
Branching is fast, flexible and easy, and useful for new
features. We do a tiny bit of this in CVS now (cl_xxx_branch,
rigid_tap, joints_axes, new-teleop, ...) but only when absolutely
necessary because the branches eventually build up and pollute the
branch/tag namespace (see cvs log). (major)
Branches are easier to keep up-to-date, solving the staleness
problem. It is easy to merge the new things on trunk with the
changes on the branch ("merge", "rebase"), giving an up-to-date
branch. We have done this manually in CVS a bit (concave_comp2,
joints_axes2), but it can be a lot of work, and the result is an
entire new branch that starts becoming stale again right away.
(major)
The administration of a central server would be easier than the
current CVS system, and more flexible. For instance the email and
irc floods when changing many directories would not happen.
(minor)
We often have a couple active branches, and applying a change to
more than one branch is easier than with CVS (specifically when it
is in more than one file). (minor)
Contributors without direct "push" access can send us patches
generated by git instead of vanilla patches, or use services like
github to publish their own branches online. This lets us push
their contribution easily, even if it consists of several commits,
and their own name will show up as the author. (major)
There are downsides to any transition, no matter what system we choose:
Work including importing our old CVS data, and setup and
administration of the new central repository. (however, most of
this work is already done)
Developers, especially those who contribute infrequently, need
to learn to use it. (git offers cvs emulation which we can use if
this proves to be necessary)
An initial git checkout transfers more data than an initial cvs
checkout. (but when using git:// or git+ssh:// transports, the "git
clone --depth" option can reduce this to near-cvs levels, and we may
be able to switch hosting to a system with more outgoing bandwidth
at the same time)
Why did we select git instead of another system?
Subversion does not have the level of decentralization of git or
bazaar -- you cannot view the full project history (log and diff)
while offline; you cannot create local branches; you cannot commit
while offline.
Bazaar and git have very similar feature sets, and in many ways it's
a toss-up. Git has a speed advantage over bazaar for many
operations[1] and a smaller repository size[2]. Bazaar doesn't have
an equivalent to 'git cvsserver', which we may want to use to ease
this change for infrequent contributors. On the other hand, Bazaar
can apparently treat git branches as 'foreign branches', so a
dedicated bazaar user can follow emc2 development in bzr[3]. At
the Wichita fest, Seb Kuzminsky expressed that while he prefers
bazaar to git, git is so much better than cvs that he would only be
pleased with the change.
Mercurial, arch, and other lesser-known systems systems don't have
the user base that git has, and we want to avoid adopting a system
that will not be actively maintained for the next decade or so.
We welcome discussion about this, because there may be dealbreakers
in git that we're not aware of yet, or a killer feature in another
system that we haven't considered.
What is the schedule for the conversion?
We hope to convert by mid summer. More announcements with specific
dates will be forthcoming.
Who will have commit access to the new system?
Everyone who has submitted ssh keys for the current server will have
commit access to the linuxcnc.org git repository. As now, new
contributors will be considered on the basis of submitted patches.
How can I take git for a test drive?
There is an experimental import of the full emc2 history into git.
If you're using Ubuntu Hardy, you can easily take it for a test
drive. (for Ubuntu Dapper, it will probably be necessary to install
git-core from dapper-backports[4], but we haven't tested this yet)
First, install the following packages:
git-core
curl
Optionally:
gitk or qgit
git-gui
Clone ("checkout" in cvs parlance) the repository:
git clone http://linuxcnc.org/git-repos/emc2-experimental.git emc2-git
this will create a new local directory 'emc2-git' and fetch the full
history of the project. On a system with a 3 megabit connection,
this took about 5 minutes and the created directory is about 100
megs.
Take a look at the history:
cd emc2-git
git log -C --stat
Get a closer look at a particular change by commit:
git log -C -p -1 57c609
View history graphically, if you installed the necessary program:
gitk --all
qgit --all
You can also view the project history online in gitweb:
http://linuxcnc.org/gitweb/
Edit some files and then commit the changes locally:
git commit -a -m"my well-intentioned changes"
(use 'git gui' to have fine-grained, graphical control over what
you're committing, or 'git add' for the commandline/text oriented
folks)
Pull changes made by another developer but not yet committed to the
central repository:
git pull git://git.unpythonic.net/emc2-ignores.git master
(this pulls two commits that change old .cvsignore files to new .gitignore
files and add some missing items to .gitignore)
To work on the 2.3 branch instead of 'master' ('master' is the git
equivalent of cvs 'TRUNK'):
git branch --track v2_3_branch origin/v2_3_branch
git checkout v2_3_branch
While on the branch, apply a bugfix from the master:
git cherry-pick 57c609
After you branch, you can switch freely between master and branch:
git checkout master
git checkout v2_3_branch
If you want to know more about git, visit the git website which has
a ton of docs linked from the front page:
http://git-scm.com/
There is a git tutorial:
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
"Everyday GIT":
http://www.kernel.org/pub/software/scm/git/docs/everyday.html
"Git for the lazy":
http://www.spheredev.org/wiki/Git_for_the_lazy
Jeff Epler, speaking for the emc board of directors:
Alex Joni
John Kasunich
Stephen Wille Padnos
Chris Radek
[1]
http://git.or.cz/gitwiki/GitBenchmarks#bzr.2Cgit.2CandhgperformanceontheLinuxtree
[2]
http://git.or.cz/gitwiki/GitBenchmarks#Git.2CMercurial.2CBazaarrepositorysizebenchmark
[3] http://bazaar-vcs.org/BzrForeignBranches#Git
[4] http://packages.ubuntu.com/source/dapper-backports/git-core
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
