Hi,
I'm new to emc-developpers list, so I decided to shut up over this. But I
personnally think that bzr on lauchpad would have been a much more sensible
choice. bzr offer an svn-mode which is quite handy for IDE with source-control
integration.
linuxcnc.org would have then hosted the wiki/website/documentation part of the
project.
On June 4, 2009 08:35:57 pm paul_c wrote:
> 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
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
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
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
