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