From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: What a modern collaboration toolkit looks like Date: Thu, 03 Jan 2008 10:26:16 +0900 Message-ID: <87prwj1yyv.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20080101171120.GC3830@muc.de> <20080101.190535.32709273.wl@gnu.org> <20080101182742.GE3830@muc.de> <20080101.192802.05328072.wl@gnu.org> <20080102121745.GD17588@thyrsus.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199323454 29060 80.91.229.12 (3 Jan 2008 01:24:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Jan 2008 01:24:14 +0000 (UTC) Cc: acm@muc.de, eliz@gnu.org, Richard Stallman , esr@snark.thyrsus.com, emacs-devel@gnu.org To: esr@thyrsus.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 03 02:24:34 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 1JAEoy-0006p8-Jj for ged-emacs-devel@m.gmane.org; Thu, 03 Jan 2008 02:24:32 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JAEoc-0001B3-EL for ged-emacs-devel@m.gmane.org; Wed, 02 Jan 2008 20:24:10 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JAEmT-0008WP-59 for emacs-devel@gnu.org; Wed, 02 Jan 2008 20:21:57 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JAEmR-0008WD-IZ for emacs-devel@gnu.org; Wed, 02 Jan 2008 20:21:56 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JAEmR-0008WA-FE for emacs-devel@gnu.org; Wed, 02 Jan 2008 20:21:55 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JAEmK-0005Dm-4r; Wed, 02 Jan 2008 20:21:48 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id A2A731535B3; Thu, 3 Jan 2008 10:21:44 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5090E1A29E5; Thu, 3 Jan 2008 10:26:17 +0900 (JST) In-Reply-To: <20080102121745.GD17588@thyrsus.com> X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" (+CVS-20070621) XEmacs Lucid 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:85961 Archived-At: *sigh* And I just finished writing a private message saying I didn't want to get involved. Eric S. Raymond writes: > CVS and Subversion try to maintain a linear version history unless you > do explicit branching. So when you commit a change against an out-of-date > revision, they raise a conflict; you have to merge news before being > allowed to finish the commit. > > In modern DVCSes, a push never blocks. I think you've typoed "push" for "commit". Specifically: This conflicts with Mercurial terminology. *commits* never block in Mercurial. *Pushes* do, unless you use "hg push -f" (which creates an alias-less head in the target repo---its only names are the revno and the hash). I suspect what you meant to say here is that "In a modern DVCS, a commit never blocks". The reason that "commit" blocks in CVS and SVN is because in those VCSes "commit" can be considered equivalent to a Mercurial "commit + push". Ie, CVS and SVN commits can block because pushes always can block, and every commit implies a push. Proliferating new heads in the public repo is antisocial; that's what local repos are for. Unfortunately, (loosely speaking) CVS and SVN don't support local repos, so there's no way to separate commit and push for most projects. If the push blocks, the commit must do so. > This is certainly the way monotone, Mercurial, and bzr operate. If "push" wasn't a typo, please recheck your information on monotone and bzr, too. I find it hard to believe that they silently allow pushes to succeed when they would create new heads; this is a recipe for disaster. > As I said, I have not yet studied git specifically but I'm pretty > sure it works the same way. Like Mercurial, git blocks if you try to push a branch to a ref which is not a prefix of the branch you're pushing. Unlike Mercurial, "git push -f" just does what you tell it to do (push a bunch of objects and set the ref to the same commit as HEAD points to locally), and therefore will create garbage (lost commits and their dependent objects) in most cases. It does not create an implicit new head (which can have no reference except its SHA1, and thus is pretty useless). Neither behavior seems particularly useful to me. BTW, to be honest, I think "commit-before-merge" is a good advertising slogan, but it doesn't promote understanding of how dVCSes work, and only offers the GUI/CADT/IRC/XP view of their advantages.