From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Strange message from "bzr pull" Date: Wed, 30 Dec 2009 02:02:26 -0500 Message-ID: References: <877hs5ogv8.fsf@red-bean.com> <83my11ejmr.fsf@gnu.org> <87aax1mxh6.fsf@red-bean.com> <83hbr9eha3.fsf@gnu.org> <87ws05lhqg.fsf@red-bean.com> <83d41xee5d.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1262156589 10621 80.91.229.12 (30 Dec 2009 07:03:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Dec 2009 07:03:09 +0000 (UTC) To: kfogel@red-bean.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 30 08:03:01 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 1NPsaD-0006kx-6v for ged-emacs-devel@m.gmane.org; Wed, 30 Dec 2009 08:03:01 +0100 Original-Received: from localhost ([127.0.0.1]:44712 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPsaD-0004tF-Et for ged-emacs-devel@m.gmane.org; Wed, 30 Dec 2009 02:03:01 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NPsa4-0004rB-Px for emacs-devel@gnu.org; Wed, 30 Dec 2009 02:02:52 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NPsZz-0004m5-8D for emacs-devel@gnu.org; Wed, 30 Dec 2009 02:02:51 -0500 Original-Received: from [199.232.76.173] (port=59394 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPsZz-0004m1-2f for emacs-devel@gnu.org; Wed, 30 Dec 2009 02:02:47 -0500 Original-Received: from [140.186.70.10] (port=53872 helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NPsZy-00044E-I2 for emacs-devel@gnu.org; Wed, 30 Dec 2009 02:02:46 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1NPsZe-0003DO-8A; Wed, 30 Dec 2009 02:02:26 -0500 In-reply-to: <83d41xee5d.fsf@gnu.org> (message from Eli Zaretskii on Tue, 29 Dec 2009 22:09:02 +0200) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:119022 Archived-At: > Date: Tue, 29 Dec 2009 22:09:02 +0200 > From: Eli Zaretskii > Cc: lekktu@gmail.com, emacs-devel@gnu.org > Reply-To: Eli Zaretskii > > > From: Karl Fogel > > Cc: lekktu@gmail.com, emacs-devel@gnu.org > > Date: Tue, 29 Dec 2009 14:09:43 -0500 > > > > >OK. So, since we have this tree in trunk/, what are the reasons to > > >keep it pristine, again? IOW, why not make quick and simple fixes in > > >it directly, instead of in another branch? > > > > I *think* that would work fine (though I'm not 100% positive, since I > > don't do it myself). > > > > The only reason I didn't document that is that if upstream gets new > > changes while the local edits are being made, then one would have to > > pull them in before committing -- because, as a bound branch, trunk is > > not supposed to diverge from what it's bound to. But they might > > conflict. Now your local trunk mirror is in a conflicted state. > > Yes, understood. But I didn't intend to make any serious changes > there, just the ``one-offs''. If only one or two files are modified, > things will not become too ugly, I think, even if there are conflicts. So what, if any, changes in the bzr configuration and in the workflow documented on the wiki would be necessary if the trunk/ tree is used for small one-off fixes? I understand that by binding this branch to the remote repository, we actually made it a checkout. Therefore, "bzr pull" that is documented on the wiki will only work if I have no local changes that are not committed to the central repository; otherwise, I need to use "bzr update", is that right? If so, perhaps it's better to say on the wiki that "bzr update" be always used in trunk/, because it will always work, no matter if the mirror diverged or not? Next, what is this public_branch directive in .bzr/branch/branch.conf. Its documentation in the manual is abysmally inadequate, but it sounds like it is only used in "bzr send"? If so, making changes in trunk/ does not need to change this (or any other) line in branch.conf, is that right? Any other consequences I missed? TIA