From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Strange message from "bzr pull" Date: Tue, 29 Dec 2009 14:09:43 -0500 Message-ID: <87ws05lhqg.fsf@red-bean.com> References: <877hs5ogv8.fsf@red-bean.com> <83my11ejmr.fsf@gnu.org> <87aax1mxh6.fsf@red-bean.com> <83hbr9eha3.fsf@gnu.org> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1262113804 7539 80.91.229.12 (29 Dec 2009 19:10:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Dec 2009 19:10:04 +0000 (UTC) Cc: lekktu@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 29 20:09:57 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 1NPhS9-0002Vw-H1 for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2009 20:09:57 +0100 Original-Received: from localhost ([127.0.0.1]:59420 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPhS9-00029Q-Uc for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2009 14:09:57 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NPhS4-000295-KG for emacs-devel@gnu.org; Tue, 29 Dec 2009 14:09:52 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NPhS0-00028T-16 for emacs-devel@gnu.org; Tue, 29 Dec 2009 14:09:52 -0500 Original-Received: from [199.232.76.173] (port=44085 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPhRz-00028Q-TO for emacs-devel@gnu.org; Tue, 29 Dec 2009 14:09:47 -0500 Original-Received: from sanpietro.red-bean.com ([66.146.206.141]:33620) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NPhRw-00057e-H5; Tue, 29 Dec 2009 14:09:44 -0500 Original-Received: from localhost ([127.0.0.1]:40644 helo=floss ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.71) (envelope-from ) id 1NPhRv-0000jg-HU; Tue, 29 Dec 2009 13:09:43 -0600 In-Reply-To: <83hbr9eha3.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 29 Dec 2009 21:01:24 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (gnu/linux) 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:118960 Archived-At: Eli Zaretskii writes: >> From: Karl Fogel >> Date: Tue, 29 Dec 2009 13:44:21 -0500 >> Cc: lekktu@gmail.com, emacs-devel@gnu.org >> >> Eli Zaretskii writes: >> >So does that mean there's a bug in bzr? If not, then what are >> >tree-less repositories good for? >> >> The answer to that is "many thing", I think, just not things we happen >> to be doing here. > >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. That's not a disaster -- it's easy enough to resolve things -- but the point of the trunk mirror is that it's always pristine, so that it can be used as a merge source for your local feature branches, etc. That's why in the other recipes, if you get conflicts, we just say "bzr revert" and pull, and then re-merge from the local branch to commit upstream. However, in this scenario, "bzr revert" would lose the *only* copy of the changes, unlike in all the other scenarios. So you really have to resolve the conflict right away, without reverting, and finish the commit. Thus trunk spends more time in a non-pristine state than is ideal, though it's not hard to get out of that if one needs to. None of this is terribly complicated, and I doubt any developer here would have a problem handling it, but I wasn't sure it was wise to introduce that little bit of extra complexity early on, especially as I didn't have personal experience with it and didn't know if the likelihood of unexpected gotchas. So if you test it and it works, and no one thinks of any reason why it could lead to bad history, then... go for it, I'd say. -Karl