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: bzr repository ready? Date: Tue, 24 Nov 2009 11:04:33 +0900 Message-ID: <87my2cptji.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20091118230952.GB908@muc.de> <87my2jw05z.fsf@red-bean.com> <83skc9pbf7.fsf@gnu.org> <87iqd5vw5n.fsf@red-bean.com> <877htl53tc.fsf@telefonica.net> <87ws1ku7zd.fsf@red-bean.com> <87hbso4s13.fsf@telefonica.net> <83aaygoy90.fsf@gnu.org> <87vdh36d48.fsf@telefonica.net> <831vjrptha.fsf@gnu.org> <87einr63b6.fsf@telefonica.net> <83y6lzo9e7.fsf@gnu.org> <871vjr750o.fsf@uwakimon.sk.tsukuba.ac.jp> <87zl6fnnu2.fsf@notengoamigos.org> <87aaye3nba.fsf@uwakimon.sk.tsukuba.ac.jp> <87r5rqm7gm.fsf@notengoamigos.org> <87skc5spso.fsf@uwakimon.sk.tsukuba.ac.jp> <87ws1hujh5.fsf@notengoamigos.org> <4B0B1DA6.7030206@harpegolden.net> <87k4xgrdsl.fsf@canonical.com> <4B0B34AF.20400@harpegolden.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1259027941 32242 80.91.229.12 (24 Nov 2009 01:59:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Nov 2009 01:59:01 +0000 (UTC) Cc: es , Eli Zaretskii , Karl Fogel , Jason Earl , emacs-devel@gnu.org To: David De La Harpe Golden Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 24 02:58:53 2009 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 1NCkg7-0002YZ-Ds for ged-emacs-devel@m.gmane.org; Tue, 24 Nov 2009 02:58:51 +0100 Original-Received: from localhost ([127.0.0.1]:49329 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCkg6-0007xl-Dn for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 20:58:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCkg2-0007wK-0h for emacs-devel@gnu.org; Mon, 23 Nov 2009 20:58:46 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCkfw-0007sK-Vq for emacs-devel@gnu.org; Mon, 23 Nov 2009 20:58:45 -0500 Original-Received: from [199.232.76.173] (port=58893 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCkfw-0007rr-Pa for emacs-devel@gnu.org; Mon, 23 Nov 2009 20:58:40 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:34932) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCkfk-0003B4-4u; Mon, 23 Nov 2009 20:58:28 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 83A69820D; Tue, 24 Nov 2009 10:58:26 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id ADD691A28C6; Tue, 24 Nov 2009 11:04:33 +0900 (JST) In-Reply-To: <4B0B34AF.20400@harpegolden.net> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" d20e0a45a4b2 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/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:117657 Archived-At: David De La Harpe Golden writes: > That's the thing - Are you skipping a step here? At least, you've > got no _manifest_ local mirror of UB. You don't have one in git, either, only a ref labelled with the remotes/ prefix. > Why aren't I implicitly or explicitly making a local > remote-tracking branch RB mirroring UB, then local branch LB ? In the recommended workflow in BzrForEmacsDevs, "trunk" is precisely a manually-maintained remote tracking branch. bzr will not do this for you, you have to do it yourself. > *** Except for the bit where someone ...commits local changes on it... > Wait, what? You don't commit any local changes, because you didn't make any in that branch. You *merge* local changes to it from your working branch, and these are *automatically* passed on to the upstream master when you commit. > Fortunately, I'm not an upstream committer, I'll presumably be sending > or asking upstream committers to pick stuff from my public tree, but > still, I'm clearly missing something. No, actually you're not missing anything. At least, you've already noticed that bzr is not git, and that's all that's going on here. > and then commit > > bzr commit -m "Merge: fix bla bla bla (closes Bug #1)." > > which automatically pushes all your new commits to the upstream master, > because the mirror is set up as bound branch. > """ > > *** why is this happening on branch trunk Because branch trunk is bound to the upstream master, it is not possible to commit unless the implied push is a fast-forward. This is exactly what you want; if the commit fails, you simply do "bzr pull --overwrite" (or "bzr revert; bzr pull", I forget which I wrote in BzrForEmacsDevs), and then do the "merge-to-SOMETASK, maybe fix merge conflicts, merge-back-to-trunk" dance again. > and not a branch my-trunk branched from trunk? Because it's pointless to do that. The race condition in using my-trunk (not bound to upstream master) means that you can succeed in committing the merge, but fail the push. So you rm -rf my-trunk[1], and start over, with "bzr branch trunk my-trunk". Yuck. If my-trunk *is* bound to upstream master, things work nicely (losing the race is fail-safe), but branch "trunk" is redundant. Footnotes: [1] In principle. It's actually feasible to rollback history in this case, but there's no way I'm going to describe that in a document for newbies because the conditions for safety require a lot of understanding of bzr theory of ops.