From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Re: Repo cpnversion progress report Date: Fri, 31 Jan 2014 16:51:24 -0500 Organization: Eric Conspiracy Secret Labs Message-ID: <20140131215124.GB19192@thyrsus.com> References: <20140130195557.GA8405@thyrsus.com> <83iot16u66.fsf@gnu.org> <20140130214201.GA9204@thyrsus.com> <83ha8k7fp0.fsf@gnu.org> <87iot0f481.fsf@ktab.red-bean.com> <20140131181612.GA18170@thyrsus.com> Reply-To: esr@thyrsus.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1391205094 29288 80.91.229.3 (31 Jan 2014 21:51:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Jan 2014 21:51:34 +0000 (UTC) Cc: Karl Fogel , Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 31 22:51:42 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W9Lzy-0004zI-2Q for ged-emacs-devel@m.gmane.org; Fri, 31 Jan 2014 22:51:42 +0100 Original-Received: from localhost ([::1]:58463 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9Lzx-00068n-Ox for ged-emacs-devel@m.gmane.org; Fri, 31 Jan 2014 16:51:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53526) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9Lzr-00068e-9o for emacs-devel@gnu.org; Fri, 31 Jan 2014 16:51:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W9Lzm-0004Ba-Tj for emacs-devel@gnu.org; Fri, 31 Jan 2014 16:51:35 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:37678 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9Lzh-0004A4-6C; Fri, 31 Jan 2014 16:51:25 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 39C80380695; Fri, 31 Jan 2014 16:51:24 -0500 (EST) Content-Disposition: inline In-Reply-To: X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169300 Archived-At: Stefan Monnier : > > I hear the argument about forensics, but the Bazaar revision numbers > > are no more helpful for that than the action stamps. If anything, > > spelunking is an argument for appending those numbers to the change > > comment of each revision - leaving them in as references would a > > bass-ackwards approach to the problem. > > Moving the "equiv to bzr r123456" to the commit message of that > corresponding Git commit sounds like an good compromise. Of course, we > don't need it for every commit, but for all those commits that have > a corresponding "action stamp". Technically, I could do this. It would take a minor extension of reposurgeon, but that is in itself OK because I'm going to have to build that same primitive to do the thing Eli Zaretskii wanted (fixes-bugs headers folded into the commit comments). Let me explain this; it will give some insight into my working methods. The primitive I plan to add to reposurgeon will be called "append" or some verb like that. It will take two arguments; one commit identifier, one string. The effect will be to append the specified line to the specifed commit comment. Then, I would extract a list of revisions to be marked from my master FOSSILS file and compile it into a sequence of append commands. So, for ecample, this association: 100984 -> 2010-08-05T23:34:12Z!dann@ics.uci.edu would compile to this append command: <2010-08-05T23:34:12Z!dann@ics.uci.edu> append "\nBazaar revision 100984" For Eli's feature, I would build a map from revisions to fixes-bug numbers by mechanically analyzing the output of bzr log, then generating append commands like this: <2010-08-05T23:34:12Z!dann@ics.uci.edu> append "\nFixes bug 2317" All these append commands would be appended to the lift script to be applied on conversion day. These things can be done. The question is whether they *should* be done. Because with each benefit there also comes a cost. There is a real cost to burdening the commit comments with an ever-increasing load of fossil data. As Paul Eggert pointed out in connection with references, this will scale badly over time. Additionally, while none of these processing steps (or many others like them) are difficult in principle, they accumulate to a huge load of work for me. Accordingly, I want to hear a use-case analysis. That is, rather than relatively vague hand-waving about forensics I want somebody with a stake in the process *other than me* to lay out a set of user stories about what kinds of navigation and lookup we want to support, so that potential data representations (map file, in-commit comments, etc.) can be checked against those stories. Here's an example of a user story: Someone is reading the emacs-devel archives and reads mail containing a reference to an Emacs change by Bazaar revision. How does he get to the corresponding git revision? What other user stories are there? What do they tell us about acceptable gradients in lookup costs? What does that tell us about good metadata representations? I think I know what many of the conclusions will look like. I've been around this track before! But others might educate me, and will certainly educate some of the rest of you. > > But there's a better way. We're going to have a complete > > revision-to-action-stamp map as part of the record. It would be > > pretty easy to write Emacs code that uses that map to find revisions > > by Bazaar reference number. That's the right solution, IMO. > > But where would this map be stored? /etc, same as any other static data used by a mode. -- Eric S. Raymond