From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: bzr repository ready? Date: Sun, 22 Nov 2009 09:54:47 +0900 Message-ID: <871vjr750o.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87639fr3w7.fsf@red-bean.com> <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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1258850937 20833 80.91.229.12 (22 Nov 2009 00:48:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2009 00:48:57 +0000 (UTC) Cc: =?iso-8859-1?Q?=D3scar?= Fuentes , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 22 01:48:49 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 1NC0dD-00007Z-F5 for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2009 01:48:47 +0100 Original-Received: from localhost ([127.0.0.1]:33207 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NC0dD-0007KR-51 for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2009 19:48:47 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NC0d7-0007Jw-Ln for emacs-devel@gnu.org; Sat, 21 Nov 2009 19:48:41 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NC0d2-0007JU-Qq for emacs-devel@gnu.org; Sat, 21 Nov 2009 19:48:41 -0500 Original-Received: from [199.232.76.173] (port=45831 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NC0d2-0007JR-M2 for emacs-devel@gnu.org; Sat, 21 Nov 2009 19:48:36 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:56994) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NC0cv-0006rX-95; Sat, 21 Nov 2009 19:48:29 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id EDF39820F; Sun, 22 Nov 2009 09:48:24 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D83311A28C6; Sun, 22 Nov 2009 09:54:47 +0900 (JST) In-Reply-To: <83y6lzo9e7.fsf@gnu.org> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" d20e0a45a4b2 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:117476 Archived-At: Eli Zaretskii writes: > > From: =D3scar_Fuentes > > >> >> is not that great. First, building takes a long time. > > >> > > > >> > Why does the building take a long time in that case? [...] > > The newly created feature branch you are working on is a pristine set > > of versioned files on a new directory. If you want to test your change, > > you need to build the emacs executable, because it is not there. >=20 > Of course. But building does not take a lot of time, except for the > first time, which does a full bootstrap for that branch. I'm not sure if you are getting it, forgive me if you have: as =D3scar said, people experienced with git, and maybe Mercurial, will tell you to branch for *every* change. Why not? How often do you write a `let' expression in Lisp? -- a git branch's cost is the equivalent of a `setq', it's *way* less expensive than a `let'. But it gives you the same kind of protection from pollution of the VCS environment that a let does for a Lisp program, and at the same time allows you to checkpoint your code, or (if you're so inclined) actually record notes on what you're doing and why as you go along in the commit logs. The argument for branching extremely frequently in git is a no-brainer; the biggest cost *by far* is keeping track of branch names. If you do this in git (and in git, I do!), it's painless, because you have only one workspace for all the small changes. The branches are "colocated" in the same repository/workspace; they share a working tree. That means that a rebuild is a simple `make', and it's incremental. 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. > It's a CVS checkout of the trunk, with local changes. Each "cvs up" > merges the changes on the trunk with my local changes. Since no one > is working on the display engine, I had maybe one or two conflicts in > several months. It's really not such a big deal, even with CVS. I > don't see how any VCS could "shine" in this use-case. Maybe I'm > missing something. You are. *You* apparently don't miss having the VCS record your history as you go along, and that's OK. But many of the rest of us *do*, and for your use case + history, a dVCS shines because it's very cheap to checkpoint your work and record activity and motivation in the log, as described above. For your use case, where you don't care about history, you're right; it's hard to beat CVS by very much. Until a year from now, when Yidong comes to you and says, "what were you thinking when you wrote this code?!" and you are forced to say "I don't know" and you make the "obvious" fix and 6 months after *that* somebody inserts an Arabic obscenity into a letter to their mother because it's "I love you" spelled backwards.... Of course there are other ways to accomplish this kind of history- keeping, such as comments in the code and entries in the ChangeLog proper (lord, do I hate merging changelogs!) Again, if that works for you, OK. But I and many others find it useful to have the VCS manage that task, specifically because unlike a ChangeLog, it provides the exact patch that goes with the changelog.