From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Uday S Reddy Newsgroups: gmane.emacs.devel Subject: Re: Locks on the Bzr repository Date: Sat, 21 Aug 2010 13:31:29 +0100 Message-ID: <19567.50977.609000.549262@gargle.gargle.HOWL> 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> <83aaogpcbu.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1282393953 8499 80.91.229.12 (21 Aug 2010 12:32:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 21 Aug 2010 12:32:33 +0000 (UTC) Cc: Uday S Reddy , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 21 14:32:31 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 1OmnFK-0000R8-04 for ged-emacs-devel@m.gmane.org; Sat, 21 Aug 2010 14:32:30 +0200 Original-Received: from localhost ([127.0.0.1]:48178 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmnF1-0003dg-Lt for ged-emacs-devel@m.gmane.org; Sat, 21 Aug 2010 08:32:07 -0400 Original-Received: from [140.186.70.92] (port=46776 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmnEt-0003cp-OK for emacs-devel@gnu.org; Sat, 21 Aug 2010 08:32:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OmnEr-0002ay-LV for emacs-devel@gnu.org; Sat, 21 Aug 2010 08:31:59 -0400 Original-Received: from sun61.bham.ac.uk ([147.188.128.150]:55675) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OmnEr-0002an-C1; Sat, 21 Aug 2010 08:31:57 -0400 Original-Received: from [147.188.128.127] (helo=bham.ac.uk) by sun61.bham.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1OmnEp-0005Ic-O9; Sat, 21 Aug 2010 13:31:55 +0100 Original-Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk with esmtp (Exim 4.43) id 1OmnEp-0000vc-EE; Sat, 21 Aug 2010 13:31:55 +0100 Original-Received: from gromit.cs.bham.ac.uk ([147.188.193.16] helo=MARUTI.cs.bham.ac.uk) by mx1.cs.bham.ac.uk with esmtp (Exim 4.51) id 1OmnEo-0008Lm-Ts; Sat, 21 Aug 2010 13:31:55 +0100 In-Reply-To: <83aaogpcbu.fsf@gnu.org> X-Mailer: VM 8.1.92a under 23.2.1 [EmacsW32 Version 1.58 2010-08-02] (i386-mingw-nt5.1.2600) 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:128957 Archived-At: Eli Zaretskii writes: > 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. Well, the strategies I mentioned are common knowledge. If Stephen has some other sophisticated tricks he knows about, I am sure he will tell us. > 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. Pull works before you commit. It is the same as update, just a difference in terminology. If you commit wihout pulling first, then your branch may begin to diverge from the public repo. A bound branch won't allow you to do this. It will force you to update first. So, I can see a reason why the Stefan and Yidong might recommend bound branches. But the reasoning is weak. If I do commit push and the push fails because the branch has diverged, then my strategy is to uncommit pull commit push So, for a single commit, you can get the same effect as bound branches. If I do multiple commits to my branch and it has diverged significantly from the public repo, then I do rebase ... resolve conflicts ... test push (Even though you said you understand how rebase works, here is a quick summary. If you originally pulled at revision 500, and made commits 501..505 while the central repo moved up to revision 510 in the interim, then doing a rebase will import revisions 501..510 from the central repo and move your commits to 511..515. This has a significant advantage over bound branches. I am able to use my main branch as if it were a task branch, keep all the related commits together, test all of the commits together, push at my own convenience, reduce the time wasted in synchronization and ensure that all the commits are at the top level of the history. (Bound branches do the opposite. They intersperse your commits with others. You might end up publishing your commits before they are fully tested. And, they force you to synchronize with the central repo for each commit. In essence, bound branches are not distributed. They are centralized.) > 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. I understand. If you use unbound branches, you don't have to do this. > 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? Commiting/sychronizing "frequently" is still better than commiting instantly. It gives you a choice as to how frequently you synchronize. That might depend on the urgency of the fixes and server contention levels. Bound branches remove that choice. The overhead of rebase is also part of the choice. In cases where the overhead is significant, you might push more frequently. In cases where it isn't, you might push less frequently. As for interspersing bug-fixes and new features, I would pick and choose depending on the situation. A half-finished new feature sitting in the trunk doesn't hurt anybody. I might leave it in. (People are expected to use the new feature only after it gets into the NEWS file.) Or, if I don't feel comfortable about it, I would probably push my current main branch as a task branch, reset the main branch to the old state (using uncommit), and attend to the urgent bug fix in the main branch. Or, I might do the urgent bug fix in a new mirror of the central repo and push it. It will then reappear as part of rebase in my main branch. So, there are lots of ways of doing it. As I said, for big new features, I would use separate task branches. > 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. Agreed. > 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. Ok, here, once again are the advantages: 1. Allows you to synchronize with central repo less frequently. 2. Allows you to choose when to synchronize. 3. Keeps your related commits to the mainline together. 4. Allows you to go from bug-fixing mode to (small) development mode and back, without much pain. 5. Allows you to choose between many different workflows, and even to switch from one to the other on the fly, whereas bound branches seem to allow only one workflow. > 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. Ok, I understand. Most of my work is done during weekends as well. If I am in a bug fixing mode, I might work on several of them in a day, but perhaps synchonize only once in the day. > 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. Ok, I stand corrected. I don't have experience with long-running commits. > 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. Agreed. It is not that the synchronization itself might be blocking you for further commits (although Jason might be in a situation where that happens as well). But, when you want to synchronize, you need to resolve conflicts which you may not be ready to do at that time. You can then postpone synchronization and continue working on other commits. > 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? I agree that you are being very disciplined here. But, most of us think of update/pull/rebase as just a chore to get through before we can push/commit. Only if it gives rise to merge conflicts would we think there is need for further testing. So, the more update/pull/rebase we have to do, the more unsafe the code is. But, how much this is a problem in reality will probably depend on the project and the nature of changes being made. I don't have a lot of experience here. But it is a concern, and it got raised for me only after reading Stephen's message. > 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. Ok, for the record, I don't mean you by saying "you". I mean the emacs-developer team in general. It seems to me that the closeness to the previous workflow using CVS was perhaps the overriding criterion for the authors of the recommended workflow. The technical merits and demerits were probably not at the top of the scale. Having always used unbounded branches, I came into this discussion wanting to learn why bound branches are being used by you guys. I still don't know why. But I can see that it makes you feel a lot more comfortable. Cheers, Uday