From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jason Earl Newsgroups: gmane.emacs.devel Subject: Re: bzr repository ready? Date: Sun, 22 Nov 2009 17:05:13 -0700 Message-ID: <87r5rqm7gm.fsf@notengoamigos.org> References: <87vdhfpil2.fsf@red-bean.com> <87einvxy9c.fsf@red-bean.com> <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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1258934833 26686 80.91.229.12 (23 Nov 2009 00:07:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Nov 2009 00:07:13 +0000 (UTC) Cc: =?utf-8?Q?=C3=93scar?= Fuentes , Eli Zaretskii , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 23 01:07:05 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 1NCMSP-0008CY-7M for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 01:07:05 +0100 Original-Received: from localhost ([127.0.0.1]:47766 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCMSO-00024d-Lg for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2009 19:07:04 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCMRJ-0001C0-A3 for emacs-devel@gnu.org; Sun, 22 Nov 2009 19:05:57 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCMRE-00017R-IH for emacs-devel@gnu.org; Sun, 22 Nov 2009 19:05:56 -0500 Original-Received: from [199.232.76.173] (port=40684 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCMRE-00017B-09 for emacs-devel@gnu.org; Sun, 22 Nov 2009 19:05:52 -0500 Original-Received: from mailout03.yourhostingaccount.com ([65.254.253.27]:54157) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCMR4-0005pk-Ej; Sun, 22 Nov 2009 19:05:43 -0500 Original-Received: from mailscan18.yourhostingaccount.com ([10.1.15.18] helo=mailscan18.yourhostingaccount.com) by mailout03.yourhostingaccount.com with esmtp (Exim) id 1NCMQu-0004lE-1i; Sun, 22 Nov 2009 19:05:32 -0500 Original-Received: from impout02.yourhostingaccount.com ([10.1.55.2] helo=impout02.yourhostingaccount.com) by mailscan18.yourhostingaccount.com with esmtp (Exim) id 1NCMQt-000828-VP; Sun, 22 Nov 2009 19:05:32 -0500 Original-Received: from authsmtp08.yourhostingaccount.com ([10.1.18.8]) by impout02.yourhostingaccount.com with NO UCE id 8Q5L1d0020ASqTN0000000; Sun, 22 Nov 2009 19:05:20 -0500 X-EN-OrigOutIP: 10.1.18.8 X-EN-IMPSID: 8Q5L1d0020ASqTN0000000 Original-Received: from jearl.fttp.xmission.com ([166.70.233.10] helo=jearl-netbook) by authsmtp08.yourhostingaccount.com with esmtpa (Exim) id 1NCMQi-0006T0-QX; Sun, 22 Nov 2009 19:05:21 -0500 In-Reply-To: <87aaye3nba.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Sun, 22 Nov 2009 18:45:29 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAAAAAByaaZbAAAABGdBTUEAALGPC/xhBQAAAAFz UkdCAK7OHOkAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAAAAlw SFlzAAASmwAAEpsB4JJZDAAAAAl2cEFnAAAAMAAAADAAzu6MVwAAAaFJREFUSMe1VtuxxSAIzIz9 2Iyl2Aj1bBX0k5+LrwjGjJyPy2ROwtGNBJbVCwwwy1UNoOL3f+SBxkj15Lr4NsboN24DWMZxYQNA TjGmjC1gswJiqBbpDeANYMwXBFyAFB5L7ADMBcoSDgAFBSDHR2tA8ABMSB4AawB76pAnILsKx2lm 1VfpgUi3kxrySylRHdmQj40Jva2/jl8EY3Twv/phhsC9nIQR0hnAOUptYsL3RxvAk+YIH2AWsvTH GYBgKn8GaPYm5jNANaCQ8WfAzyH9x0crFfGl9X4QVdg8gEqN2KjBHi6V/iBq6iyAxTqd+Yvupwai VwM9LZkxQ6otihmS6H+mHlK5URwi0UQgWxHoxS5JagBSed7IzJRCallS2pg2QsamcGUFNSHgLZUv augJIUualv1Bv6+yVat1oeMq92s/mBBWQJH7dQX7CnpvWWs/4CazpHlB2RR1BFSzNGdIaTbbLil8 U76BKKU0GztapXP3C78bNYQ6MTQybY8OkIaITf9HPzyHkXE4YXs4mf5VDz+jAepj3RTQ3Ubv0SPy 9AcCrfKh0TBgvgAAACV0RVh0Y3JlYXRlLWRhdGUAMjAwOS0wOC0yN1QxNjoxMTozMy0wNjowMFPN ssMAAAAldEVYdG1vZGlmeS1kYXRlADIwMDktMDgtMjdUMTY6MTE6MzMtMDY6MDAMfMT3AAAAAElF TkSuQmCC X-EN-UserInfo: f8a5a3c49e1c4664ba81facb1022c4a9:67ddfe7aeaee6d1ea5b788d961d42633 X-EN-AuthUser: jearl@notengoamigos.org X-EN-OrigIP: 166.70.233.10 X-EN-OrigHost: jearl.fttp.xmission.com X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:117526 Archived-At: "Stephen J. Turnbull" writes: > Jason Earl writes: > > "Stephen J. Turnbull" writes: > > > > > But Bazaar branches *cannot* at present be colocated; they > > > *cannot* share a working tree. That means that if you do a "bzr > > > branch" for a one-line change, you have to do a "make bootstrap" > > > to test. EEEEEEeeeeeewwwwww. > > > > That's not entirely true. I keep a "workspace" checkout in my > > repository and then "bzr switch" between the branches that I am > > working on. > > Sure, what I wrote isn't 100% accurate. But it's close enough, and > reasonably intelligible to novices (at least I tried to make it so). > > So please, as Eli implicitly requested, let's talk one workflow at a > time. I'm fine if you want to change to a different workflow which is > admittedly better, but what you just wrote is not an explanation of a > different workflow, or even an admission that you *are* talking about > a different workflow. It's merely a laundry list of new vocabulary > for novices to learn, with no definitions. And Eli *did* ask about > the workflow I wrote about. In more detail: > > In git the workflow in question is > > 1. Observe an issue. Plan a design and task to deal with it. > 2. "git checkout -b issue-oriented-task" # create and checkout new > branch. > 3. Hack away. > 4. "git commit -a -m 'Here is a problem and how I solved it.'" > 5. "make" > 6. Run tests. > 7. If problems, goto 4. > 8. "git checkout master; git merge issue-oriented-task; git push" > > These git operations are very fast and transparent; this is a winning > workflow. In bzr, the same workflow is implemented On the one hand you chide me for adding a slight change to the bzr workflow that you were criticizing while, on the other hand, you bring up an entirely different set of tools. If the criticism of bzr is that it doesn't have colocated branches requiring several instances of "make bootstrap" then here is how you solve it. If what you want to do is talk about how great git is, then I suppose that is helpful as well, but it certainly isn't going to help Emacs developers that are switching to bzr. The revised example assumes that you have a mirror branch named "trunk" and a light checkout named "workspace" created in the bzr repository like this: bzr co --lightweight trunk workspace > 1. Observe an issue. Plan a design and task to deal with it. > 2. "bzr branch trunk issue-oriented-task" > 3. "cd issue-oriented-task" 3 (revised). cd workspace ; bzr switch ../issue-oriented-task > 4. Hack away. > 5. "bzr commit -m 'Here is a problem and how I solved it.'" > 6. Prepare to test: "make bootstrap" 6 (revised). "make" > 7. Run tests. > 8. If problems, goto 4. > 9. "cd ../trunk; bzr merge issue-oriented-task; bzr commit; bzr push" With that one minor change the bzr workflow works just like the git one. Of course, it assumes that you have a checkout in your repository called "workspace" where you do your work, but creating such a checkout is a single command. You can even leave off the --lightweight flag and it will work precisely the same (at least from an end user's point of view). > This workflow sucks because steps 2 and 6 are slow, but people more > familiar with git than bzr are likely to remember it, adopt it > themselves (and be frustrated and switch back to git), and recommend > it to novices (who will also experience frustration). If the repository is created with --no-trees, or if the step 2. is replaced with "bzr branch --no-tree trunk issue-oriented-task" then step 2 is basically instantaneous. On my underpowered Dell netbook running Ubuntu GNU/Linux this is how long it takes to create a branch in bzr if a workspace is not created: time bzr branch --no-tree trunk/ foo Branched 98737 revision(s). real 0m0.771s user 0m0.680s sys 0m0.088s I am sure git does it in half the time, but bzr is fast enough in this case that I doubt anyone would care. Since you are reusing the workspace (like git) now step 6 is precisely the same as the git workflow. > Now you're suggesting an alternative which is just about as efficient > as the git workflow. *But* there's an important difference. Both > workflows described above depend only on the existence of a mirror > branch; otherwise they are standalone, they work just as well for a > single contribution as for a regular contributor. The workflow you > are suggesting, though, has some components that look like the above, > and others that involve preexisting context (several branches, for > example) and new commands which are actually old commands with new > names (bzr switch, at least). Somebody needs to explain all that (and > it's not going to be me, unless Tim O is about to offer me a book > contract ;-). For one off contributions the bzr workflow probably looks like this. 1. bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk/ emacs 2. cd emacs 3. hack 4. bzr commit -m "Hooray I fixed it" 5. Test 6. If problems 3 7. bzr send -o awesome-fix.patch For CVS refugees that have commit rights and aren't interested in leveraging bzr as a DVCS they can basically keep precisely the same workflow that they currently use. 1. bzr co [the magical ssh url that I don't happen to know] emacs 2. cd emacs 3. hack 4. bzr up (no -dP needed) 5. bzr commit The difference is that bzr will probably be faster for basically every operation than CVS because it has a local cache. Emacs' vc-mode stuff will even do the right thing. For this group bzr is almost certainly a more straightforward change than git. For example, there is no need to worry about the push, pull, or merge commands. Nor is there any requirement to learn about how git juggles branches. Perhaps best of all vc-mode will work just like it always has. Clearly, these are extreme cases, but they are cases that appear to apply directly to Emacs development. For those whose needs lie somewhere in between it is probably a good idea to create a repository that includes a light checkout that can be switched to various branches so that you don't have to "make bootstrap" more than necessary. This requires a few extra steps (two extra steps, that only need to be done once, to be precise), but unlike git, bzr doesn't force you to worry about branches unless you actually want to start dealing with them. If, like Eli, you aren't convinced that a DVCS is for you, then bzr won't force you to learn to use one. On the other hand if you really like git's colocated branches bzr can be easily set up to approximate them. Jason