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: The fixes-bug field Date: Thu, 16 Jan 2014 13:08:09 -0500 Organization: Eric Conspiracy Secret Labs Message-ID: <20140116180809.GB17770@thyrsus.com> References: <20140116141315.CA3BE380835@snark.thyrsus.com> <20140116163011.GC17303@thyrsus.com> <83d2jr3ly9.fsf@gnu.org> 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 1389895731 4712 80.91.229.3 (16 Jan 2014 18:08:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jan 2014 18:08:51 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 16 19:08:58 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 1W3rNB-0000fG-L3 for ged-emacs-devel@m.gmane.org; Thu, 16 Jan 2014 19:08:57 +0100 Original-Received: from localhost ([::1]:34380 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3rNB-0002L5-5F for ged-emacs-devel@m.gmane.org; Thu, 16 Jan 2014 13:08:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3rN4-0002JE-3F for emacs-devel@gnu.org; Thu, 16 Jan 2014 13:08:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3rMz-0002HX-Nu for emacs-devel@gnu.org; Thu, 16 Jan 2014 13:08:50 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:60967 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3rMu-0002GC-48; Thu, 16 Jan 2014 13:08:40 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 9511A380835; Thu, 16 Jan 2014 13:08:09 -0500 (EST) Content-Disposition: inline In-Reply-To: <83d2jr3ly9.fsf@gnu.org> 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:168554 Archived-At: Eli Zaretskii : > I think we should decide on how to store this info and how to report > the fixed bugs once we switch to git, before we decide on how to > convert this data from bzr, and whether or not this justifies a new > conversion from scratch rather than reuse of the existing mirror. My tentative plan is to append a report of the fixes property to each log message that has it. In order to fix up commit references, I'm going to have to build a small database that maps Bazaar revnos to action stamps. That in turn I will use to generate a sequence of reposurgeon commands that will patch up the repository content. For the curious, an example command would look like this: [ChangeLog] filter --regex /revno 108687/2012-06-13T21:07:35Z!eggert@cs.ucla.edu/ except I'll probably add a --replace modifier to the reposurgeon filter command that avoids the regexp overhead. Building that database already requires parsing the output of bzr log. Since I have to do that anyway, parsing the fixes-bug property and associating it with the revno is not much more work. I'll generate commands that append each report to the proper commit (the equivalent of the rewriter someone else mentioned). All these commands, together with several hundred tag names and deletes, will go into a reposurgeon script that I run on conversion day. I also plan, by the way, to run a coalescence pass. There are cliques of formerly-CVS commits with identical messages that didn't get properly merged when Andreas did the CVS lift, probably because the merge time window was set too small. (This is *very* common in CVS conversions.) Yes, preparing for this will be a lot of work. Welcome to the difference between a crappy conversion done with weak tools and a really high-quality lift done with good tools and craftsmanlike attention to the individual project history. -- Eric S. Raymond