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: Everyone, please stop making my life more difficult Date: Fri, 12 Sep 2014 05:55:43 -0400 Organization: Eric Conspiracy Secret Labs Message-ID: <20140912095542.GD32586@thyrsus.com> References: <20140912043652.4D6D8380604@snark.thyrsus.com> <834mwd8j6a.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 1410515858 32003 80.91.229.3 (12 Sep 2014 09:57:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Sep 2014 09:57:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 12 11:57:33 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 1XSNbe-000090-UB for ged-emacs-devel@m.gmane.org; Fri, 12 Sep 2014 11:57:31 +0200 Original-Received: from localhost ([::1]:43845 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSNbb-0004bq-M1 for ged-emacs-devel@m.gmane.org; Fri, 12 Sep 2014 05:57:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSNa4-0002Hc-W3 for emacs-devel@gnu.org; Fri, 12 Sep 2014 05:55:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XSNa0-0000pT-Id for emacs-devel@gnu.org; Fri, 12 Sep 2014 05:55:52 -0400 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:33030 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSNZv-0000ot-LN; Fri, 12 Sep 2014 05:55:43 -0400 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 1C3A1380604; Fri, 12 Sep 2014 05:55:43 -0400 (EDT) Content-Disposition: inline In-Reply-To: <834mwd8j6a.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:174201 Archived-At: Eli Zaretskii : > > 1) People are continuing to embed bzr revision numbers like > > r99634.2.576 and r102428 in comments. Do not do this. > > There's no easy way to refer to an old commit in an unequivocal way. Its date and committer is pretty unambiguous. Better yet is a reference to text in the old commit's summary line, when that's unique (which it usually is) as that conveys information about what is being worked on and can easly be searched for. > > They're soon going to cease being meaningful, and every time > > I have to run another conversion to clean these out it costs > > me eight to ten hours. > > I thought you already have machinery in place to do that > automatically. Semi-automatically, for the short-form revision numbers. The fundamental problems here are (a) that the Emacs repository is large enough to make search and replace on these things a very expensive proposition, and (b) people cite these in variant forms, such as "r3333", "3333", and "revno:3333". Thus, I can't simply take an exhaustive list of all possible revision IDs in all their possible variant forms and massage it into search-replace commands. If I did that, a conversion run would take weeks or months, mostly searching for IDs that are never cited. Also, there are a few cases where a revision number was typoed, and it's possible to deduce what digit was added or garbled. Thus, to get the job done in finite time. I have to maintain a list of all actually existing reference cookies and update it whenever I become aware that somebody adds a new one. To give you an idea of the scale of the task, implementing the machinery and assembling the first ID list took me eight solid weeks of work. The ID list is large enough that, with read and write overhead for the repo, applying it now takes over 10 hours - during which my main and fastest machine is continuously so loaded that the regression test suite on one of my other projects tends to fail due to kernel race conditions in the pty layer. And it's worse than that. Merging in a new set of reference cookies usually takes me two or three runs, because for various technical reasons too painful to describe the reference-patching commands have to be manually corrected occasionally (this is most likely to happen on branch merges). So the overhead of fixing these things is *large*. I only try it every couple of weeks, at which point it's usually about a three-day process. It'll be longer this time. > > 2) "eliz@gnu.org-20101113210758-8ml5kibjtza5ysmb" Um. What the *hell*? > > It's a bzr revision-id. You can use it in "bzr log" or any other bzr > command that accepts a revision spec. Well, at least that makes it less arbitrary. But still soon to become meaningless, and I still have to fix it. > > This is not the time to be inventing some random new magic-cookie > > commit reference format that my tools don't know how to recognize. > > That should have been 2010-11-13T21:07:58Z!eliz@gnu.org (I think). > > I was certain you already deal with this. If not, please tell what > information you need to convert this automatically. One I have the location of one of these, it's a simple regex transformation to turn it into a ! portable revision stamp. The expensive part will be finding them all. And I can't do the replacement mechanically, because this: a reference pair consisting of a short revision ID and one of these long-form ones would get turned into two duplicate version stamps. Avoiding that is going to take wearying handhacking, and I am unhappy that it is required. I didn't ask everyone to start using portable revision stamps months ago because I like hearing myself talk - there have been real consequences because people didn't, and now I'm going to have to write more machinery to just to be sure I've *found* all these goddamned long-form IDs so I can patch them out manually. With conversion overhead making my tests take forever I figure I'm looking at maybe five days of intermittent boring shit-work to cope with this. This has been the nastiest repository conversion ever. The data is a jungle, developer cooperation has been spotty at best, and nobody will schedule a date for the pain to be *over*. > > The correct format for a commit reference that will remain > > intelligible across every VCS, forever, is this: > > > > ! > > > > Example: 2010-11-13T21:07:58Z!eliz@gnu.org > > How can I produce this automatically given the information I have > about the revision, i.e. its number and, possibly, revision-id? bzr log on the revision ID should give you the committer date and email. > Is it possible to write a command to do this? I know how to do it using a script wrapper around git log. The central bit of magic is this: git log -1 --pretty='%ci!%ce' $1 The output from that needs trivial editing in the date part. I don't know how to do the equivalent in bzr log. -- Eric S. Raymond