On Saturday 30 May 2009, Jeff Epler wrote:
> 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.
It is not for the "board" to decide on what repository is used - It is for the
project administrators AND developers. The "board" is only to provide
guidance in such matters. When a suggestion is made, ALL developers should be
consulted and the proposal discussed.
> 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)
Development with CVS does not require a connection except for commits &
updates.
> Local history makes all operations faster (minor)
Few people are really concerned with revision histories, but yes, having the
data local is faster.
> Change sets instead of per-file history makes it easier to find
> and understand a change. (major)
git is not the only RCS that offers this, but understanding the implications
of a change requires much more than a change set.
> 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)
The only real problem with CVS is when new directories are created in a
branch.
> 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)
Regardless of the RCS in use, you will get dead/stale branches.
> 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)
email/irc floods are self inflicted by someone messing with the commit scripts
and making ill advised changes.
> 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)
Most (all?) RCS systems allow contributors to generate patches. Failing that,
they can always fall back on using diff directly.
> 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)
Sourceforge provide tools and support to handle migration and administration.
> 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.
For anyone familiar with CVS, the subversion commands will be the same for
most common tasks. If offline history and diff is that important, you can run
a local repository cloned from the master repository.
> 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.
Most are better than CVS in one way or another, but what does git offer over
something like bazaar ?
> 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.
CVS works on other operating systems, not just Linux. Support for git
and "other lesser-known systems" is spotty at best. git is a relatively small
package, and as long as the supporting libraries compile, it would probably
work on another OS.
> 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.
Yet you fail to contact the very people it would directly affect and preempt
any decision.
> 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.
Reinstate Sourceforge as the primary repository and then ALL the registered
developers will have write permissions. In addition, Sourceforge provides a
mechanism for individual registered developers to manage their own ssh keys
should they wish to use them, or alternatively, a password challenge system.
The latter being useful when working on a loan computer.
> How can I take git for a test drive?
> 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.
But if you are on a dialup, a 100Mb download is going to take a long time. Not
everyone has access to 24/7 ADSL, and some still get charged per meg.
> Pull changes made by another developer but not yet committed to the
> central repository:
Therein lies one of the problems with git - It encourages fragmented
development scattered across any number of private repositories.
> If you want to know more about git, visit the git website which has
> a ton of docs linked from the front page:
Is git a suitable alternative ?
Certainly, CVS has it's weaknesses, and poke it in the right place, it is
easy to break, on the other hand, it is a stable and proven system. It
doesn't scale too well for large complex projects, but that isn't a problem
here.
git was a knee jerk reaction to problems with bitkeeper, and is primarily
driven by the needs of the Linux Kernel team. It is still evolving, and is
not suitable for everyone. For a large project with thousands of
contributors, it has demonstrated scalability, it also forced significant
changes in working practices onto Linus Torvalds and other key people.
What other alternatives can be considered, and are they supported by
Sourceforge ?
Current options are:
Bazaar
CVS
Git
Mercurial
Subversion
Have ALL the developers been contacted directly and their views canvassed ?
------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
