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: Locks on the Bzr repository Date: Sat, 21 Aug 2010 12:03:17 +0300 Message-ID: <83aaogpcbu.fsf@gnu.org> References: <4C6D56DB.7040703@swipnet.se> <4C6D8EC5.7040901@swipnet.se> <4C6E1F0A.7070506@swipnet.se> <837hjlr78p.fsf@gnu.org> <87zkwhtws5.fsf@uwakimon.sk.tsukuba.ac.jp> <83tymppj62.fsf@gnu.org> <871v9t8klf.fsf@uwakimon.sk.tsukuba.ac.jp> <83lj81pazq.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1282381383 6036 80.91.229.12 (21 Aug 2010 09:03:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 21 Aug 2010 09:03:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: Uday S Reddy Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 21 11:03:01 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 1OmjxF-0004Qx-1v for ged-emacs-devel@m.gmane.org; Sat, 21 Aug 2010 11:03:01 +0200 Original-Received: from localhost ([127.0.0.1]:37181 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmjxA-0005Ga-3H for ged-emacs-devel@m.gmane.org; Sat, 21 Aug 2010 05:01:28 -0400 Original-Received: from [140.186.70.92] (port=43543 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Omjx2-0005GU-68 for emacs-devel@gnu.org; Sat, 21 Aug 2010 05:01:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Omjx0-0004YI-7K for emacs-devel@gnu.org; Sat, 21 Aug 2010 05:01:19 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:34622) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Omjwz-0004Y6-PM for emacs-devel@gnu.org; Sat, 21 Aug 2010 05:01:18 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0L7H00L00VJIUJ00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Sat, 21 Aug 2010 12:01:16 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.220.100]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L7H00LQ2VQ2M390@a-mtaout21.012.net.il>; Sat, 21 Aug 2010 12:01:16 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:128945 Archived-At: > From: Uday S Reddy > Date: Fri, 20 Aug 2010 23:41:13 +0100 > > >> Sure. So don't do that. One (probably for values of "one" != "eliz") > >> can pull instead, and rebase when necessary to get that to succeed. > > > > Please show this workflow in more detail. Without the details, it's > > hard to tell what you suggest. You could be thinking about things > > possible with git, but not with bzr; it happened in the past. > > I think one needs to do a pull before each commit, to be safe. (Seems to be > the same as update-commit cycle for bound branches.) > > If you have already done a series of commits and lost the opportunity to pull, > then you have to rebase. > > If even that seems too far out, then you have to make your changes into a > separate branch and merge it in later. Well, Stephen refused to tell more, citing my imaginary unwillingness to know. (Since when asking a question means you don't want to know the answer?) So I guess we will never know what Stephen was talking about. Btw, pull is only possible when the branch didn't diverge from upstream, which means it is not suited well for a branch where you do development. At least AFAIU. I'm not even sure it will agree to do its job if you have uncommitted local changes. Merging into a local branch is what I had in mind, and the disadvantage with the "bzr log" output I talked about applies to that workflow. To me, it is a significant disadvantage: I use "bzr log" a lot, and it is painfully slow with the -n0 switch. As for rebase, I don't really understand what you suggest, and how it will help with an unbound branch where you develop. Perhaps you could elaborate. (I know what's a rebase and how to do it with Bazaar.) > However, we get to use our local mirror of the trunk as if it were a local > branch. We can commit to it without affecting anybody else and do a public > commit only in the end. We can commit to it as often as we please, keep a > careful log, do enough testing etc. And, this local branch can magically turn > back into a proper mirror as soon as we do a rebase-push. You can't get this > with bound branches. Your local branches have to be necessarily separate > branches, whose histories will appear as merges in the mainline. Sure. But that's in theory. In practice, you also need to consider what kind of changes you make locally. At least for me, there are 2 main kinds: bug-fixes and development of significant new features. (There's a third kind as well: when I need to make changes for the MS-DOS build, but I don't think this part will be interesting for anyone but myself.) For the first kind, it is IMO not very good to have the changes uncommitted upstream for prolonged periods of time, because people are using the development code, and the bugs annoy them. So you'd like to commit those to upstream frequently. And if you commit frequently, the proposed rebase-push workflow (IIUC) is not a real improvement, perhaps even a nuisance, because it adds the overhead of the rebase and does not save me from frequent slow commits to the master repository. And if your local commits have bug-fixes and new features interspersed, and you want to commit just the bug-fixes, won't the workflow you need for such cherry-picking become even more complicated? For the second kind of changes, I don't see how doing that on an unbound "mirror" branch is different from a separate branch whose purpose is development. A separate branch has the advantage of keeping the development separate from mainline, so I cannot by mistake commit unfinished code to upstream. It also lowers the mental burden on my mind, by keeping things spatially separated. Merges are painless either way; I generally find bzr doing its job very well when I merge. So bottom line, I see no advantages to using an unbound branch which mixes changes of different types. I agree it's probably possible to do all that with an unbound branch, but I don't see how it would relieve the pain of slow commits and slow updates/merges from upstream, which both are slow due to network traffic bzr incurs when it uses SFTP. > We use separate local branches as well, when they are appropriate. But we are > not forced to use them all the time. (Generally, I am happy to use the main > branch for a few days worth of work where I can see the end clearly. I use > separate branches for things that might take a few weeks, or things of a more > open-ended nature.) Well, you see, for me, "a few days worth of work" means in practice a few weekends of work, because I have almost no time on weekdays for any significant work. A week's worth of commits to upstream by others is most of the time significant enough to make it a PITA when you have local changes, because there isn't a week that I don't find some small bug I want to fix and commit almost immediately, to let others enjoy the fix. > With bound branches, your branch is locked up until the commit goes > through. You can't do anything while you have uncommitted changes > in your source. Why would you say that? That's not true. Nothing prevents me from editing while "bzr ci" churns away. The system is not locked, only (some) bzr operations will fail. But most of the development is not about bzr ops, its about using the editor, the compiler, and other development tools, none of which are locked up when "bzr ci" runs. > With unbound branches, we can continue working on the source even > when push is running in the background, because the source tree > doesn't have any uncommitted changes. We can also give up on the > push if necessary and continue committing to the branch. The > advantage seems quite clear to me. Seems you think that when I'm done with developing one feature or bug-fix, I immediately proceed to committing the next one. But that's not so, at least not here. Before I'm ready for the next commit, either locally or to upstream, I need to develop and test it. And that part, which is what I do most of the time, is not blocked by a running commit. > > No big deal. But the disadvantages of each workflow need to be well > > understood before making a decision which one to use. > > I can't believe that you guys really understood the disadvantages of your > current workflow before settling on it. Not entirely, which is why I constantly revise it and make amendments. But that doesn't mean I shouldn't consider the merits and demerits beforehand. After all, most bzr commands are common to all workflows, and so getting experience with them makes you smarter when making decisions about workflows you didn't yet try. > The most illuminating revelation I found in Stephen's post is that, > with bound branches, every commit is a merge. Most of the time, it > is untested and unsafe. This is the biggest disadvantage of all, if > you ask me. I don't understand this argument at all. In fact, I think it's plain false. My workflow in a bound branch is this: brz up [build the current upstream] [some minimal sanity checks to make sure upsteam works] [make changes] [build and test the modified binary] [repeat the sanity checks, fix anything that became broken] [bzr up] [if there are any changes upstream, build and test again] [repeat last two steps until "bzr up" brings no changes] bzr ci Now please tell me how can I commit code that is "untested and unsafe" with this workflow? What am I missing? > It also occurs to me that, by asking everybody to use bound > branches, you have massively increased the contention on your public > repo and the server. That is making your problems worse. For the record, I didn't write the recommended workflow (I don't even use it to the letter). It was written by 2 people who know a lot about Bazaar and dVCSs. So I trust them to have weighed the merits and demerits when they decided on that workflow. Having said that, the Emacs wiki is free for anyone to suggest alternative workflows, so if you think there are better alternatives, feel free to advertise them. There's already one such alternative there, I see no reason why there shouldn't be more of them.