From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bojan Nikolic Newsgroups: gmane.emacs.devel Subject: bzr send workflow (Was: Locks on the Bzr repository) Date: Sat, 21 Aug 2010 21:36:15 +0100 Message-ID: <87occvzosg.fsf@bnikolic.co.uk> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1282423772 4334 80.91.229.12 (21 Aug 2010 20:49:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 21 Aug 2010 20:49:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 21 22:49:29 2010 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.69) (envelope-from ) id 1Omv0G-0006Tc-4B for ged-emacs-devel@m.gmane.org; Sat, 21 Aug 2010 22:49:24 +0200 Original-Received: from localhost ([127.0.0.1]:38666 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Omv0F-0008UB-KJ for ged-emacs-devel@m.gmane.org; Sat, 21 Aug 2010 16:49:23 -0400 Original-Received: from [140.186.70.92] (port=48817 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Omunh-0005t3-OD for emacs-devel@gnu.org; Sat, 21 Aug 2010 16:36:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Omund-00034t-Q4 for emacs-devel@gnu.org; Sat, 21 Aug 2010 16:36:25 -0400 Original-Received: from out1.smtp.messagingengine.com ([66.111.4.25]:54437) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Omund-00034B-OE for emacs-devel@gnu.org; Sat, 21 Aug 2010 16:36:21 -0400 Original-Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id A48E514E; Sat, 21 Aug 2010 16:36:19 -0400 (EDT) Original-Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 21 Aug 2010 16:36:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=from:to:cc:subject:references:date:in-reply-to:message-id:mime-version:content-type; s=smtpout; bh=P3hGVC5iPgEFdZrs83LLh+eCBbM=; b=DvxadRyqrfp4p54S4w5ers+9xXukUvmfMPFaqKfJIibaWE1px/zI8/kAukVWGGyYpgfW9zf+FvbXokyF0Ev3FSD85SGZqbP+bmiHcX6OfEy+96Ebpi+3rryulbMZ3B9DCEkkHa6drHZfpcliih+kTILTEBQayXp67cqu8trdyg0= X-Sasl-enc: /LqaEGzzp17FXMcgNulQadY/rPBPVfb4+3Zw1/opkLRx 1282422979 Original-Received: from bnikolic-laptop (nat-01.alma.cl [200.2.0.129]) by mail.messagingengine.com (Postfix) with ESMTPSA id E4E50408D1C; Sat, 21 Aug 2010 16:36:18 -0400 (EDT) In-Reply-To: (Stefan Monnier's message of "Thu, 19 Aug 2010 17:40:29 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Mailman-Approved-At: Sat, 21 Aug 2010 16:49:19 -0400 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:128996 Archived-At: Hi All, As already much discussed, the problems people are experiencing are basically due to many people trying to write (in some way) to the same sftp://bzr.sv.gnu.org/srv/bzr/emacs/trunk/ location via the dumb sftp protocol. There are many ways around this, but one I did not see mentioned (maybe I missed it) is using the bzr send command to send merge "bundles" via email. This is the way bzr development itself worked while I followed it, and I've used it on some of my own projects too. I was always very impressed how well it worked. Since maybe I missed the discussion on this, I just wanted to ask if this workflow has been considered and rejected? If not, I'd be happy to offer a more detailed summary of how it works and the advantages. I imagine one possible objection to this workflow has/will be the unnecessary complication of merge history. One possible work around would be an option to the merge bundle which basically indicated that it should be rebased to the current trunk tip if this can safely be done. If people are interested I would be happy to provide more details, at least as far as I understand them. Best, Bojan -- Bojan Nikolic || http://www.bnikolic.co.uk