From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Gregory Collins Newsgroups: gmane.emacs.devel Subject: Re: What a modern collaboration toolkit looks like Date: Mon, 07 Jan 2008 12:17:22 -0500 Message-ID: References: <20071230122217.3CA84830B9A@snark.thyrsus.com> <20071231130712.GB8641@thyrsus.com> <87y7b96az8.fsf@member.fsf.org> <87fxxfnrhi.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199726537 18805 80.91.229.12 (7 Jan 2008 17:22:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Jan 2008 17:22:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 07 18:22:36 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JBvgD-0002nm-Tn for ged-emacs-devel@m.gmane.org; Mon, 07 Jan 2008 18:22:30 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBvfq-0004ib-R0 for ged-emacs-devel@m.gmane.org; Mon, 07 Jan 2008 12:22:06 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JBvcF-0000pY-Va for emacs-devel@gnu.org; Mon, 07 Jan 2008 12:18:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JBvcF-0000oc-FL for emacs-devel@gnu.org; Mon, 07 Jan 2008 12:18:23 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBvcE-0000oI-Rx for emacs-devel@gnu.org; Mon, 07 Jan 2008 12:18:22 -0500 Original-Received: from subrosa.ca ([207.210.221.19]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JBvcB-0002AM-28; Mon, 07 Jan 2008 12:18:19 -0500 Original-Received: from greg by subrosa.ca with local (Exim 4.43) id 1JBvbG-0001o5-Sg; Mon, 07 Jan 2008 12:17:22 -0500 In-Reply-To: (Richard Stallman's message of "Sat, 05 Jan 2008 00:55:46 -0500") User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.51 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:86503 Archived-At: Richard Stallman writes: > It sounds like "git push" is the real analogue of CVS commit, and that > this is the closest match-up between the concepts of git and the > concepts of CVS: > > CVS GIT > save file = commit > commit = pull or push > > But I still don't understand what step actually alters the trunk that > users will get by default from the public repository. Does `push' do > that? If not `push', then what? The discussion thusfar has been centred on the nuts and bolts of distributed version control, and I think the point that's getting overlooked is that decentralization allows you to arbitrarily redefine the topology of how change flows through a project. To make this more concrete, here are some commonly-used workflow models: 1. CVS-style / star topology ---------------------------- There is a centralized "one true repository" at a known location (e.g. http://savannah.gnu.org/.../hg/emacs-trunk). A medium-sized group of hackers have "push" rights there. (It's the "push" that alters the trunk here.) This approach doesn't scale well, although for emacs the commit rate is probably low enough that this topology is manageable. (That said, how many times have you asked "who committed this wonky change that broke X?" this year?) 2. "Lieutenant" / "subsystem percolation" ------------------------------------------ There is a "canonical" version of emacs that lives on savannah. (This is always true so I'll stop mentioning it.) The project is split by subsystem (and possibly is split further, resulting in a tree structure), and for each a maintainer keeps a source tree with changes to that given subsystem. When two subsystems need to be updated simultaneously due to an interface change, the lieutenants coordinate amongst themselves, pulling changes between each other. When a change is deemed ready to go to trunk (or to a parent node in the tree), the upstream maintainer pulls these changes into her tree. Note here that changes are only pulled, never pushed. Very often, subsystem maintainers "merge down" changes from trunk, so that bugfixes/stable new features from other branches are continually integrated. Everyone works hard to ensure that changes don't break anything upstream. (cf. the ongoing VC-mode restructuring; under this scheme those changes would not have been pushed to trunk until they were complete and tested.) This approach scales VERY well (it's what linux-kernel uses, and their code churn rate is *incredible*) but is probably wrong for emacs. 3. Mailing list w/ gatekeeper(s) --------------------------------- This is how mercurial manages its own development. Proposed changes are sent in patch form to a mailing list, which is dedicated to the discussion and review of such patches. The central repository is read-only except for a small set of integrators. When a change has been reviewed + tested, an integration crew member pulls the patch from email into the central tree. This is the approach I'd suggest for emacs (and it's the one we instituted for the project I maintain at my workplace). The main advantages: - code gets reviewed by more eyes. Cf. the emacs-devel+emacs-commit lists; it's my observation that bad changes are often discussed + reviewed AFTER they've been committed to the trunk. How many questionable or marginal changes are slipping by, do you think? - VC tools streamline the process of sending + reviewing changes. I can type "hg email tip" from my working branch to send my last changeset to the list for discussion. On the negative side, this approach becomes asymptotically less efficient as the number of patches per day increases. However: the beauty of distributed version control is that you can rework your topology at will. To get a flavour for how this process works from a cultural standpoint, you can read the mercurial-devel mailing list archive at: http://selenic.com/pipermail/mercurial-devel/ Thanks, Gregory Collins