From: "Eric S. Raymond" <esr@thyrsus.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Everyone, please stop making my life more difficult
Date: Fri, 12 Sep 2014 05:55:43 -0400 [thread overview]
Message-ID: <20140912095542.GD32586@thyrsus.com> (raw)
In-Reply-To: <834mwd8j6a.fsf@gnu.org>
Eli Zaretskii <eliz@gnu.org>:
> > 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 <RFC3339-date>!<committer-email>
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:
> >
> > <RFC3339-date>!<email-address>
> >
> > 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.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
next prev parent reply other threads:[~2014-09-12 9:55 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-12 4:36 Everyone, please stop making my life more difficult Eric S. Raymond
2014-09-12 6:08 ` Eli Zaretskii
2014-09-12 9:55 ` Eric S. Raymond [this message]
2014-09-12 10:33 ` Eli Zaretskii
2014-09-12 10:49 ` Gregor Zattler
2014-09-12 13:05 ` Eli Zaretskii
2014-09-12 13:19 ` David Kastrup
2014-09-12 13:29 ` Eli Zaretskii
2014-09-12 13:55 ` Andreas Schwab
2014-09-12 14:12 ` Eli Zaretskii
2014-09-12 15:17 ` Eli Zaretskii
2014-09-12 15:21 ` Andreas Schwab
2014-09-12 17:15 ` Eli Zaretskii
2014-09-12 17:43 ` Andreas Schwab
2014-09-12 15:53 ` David Kastrup
2014-09-12 17:22 ` Eli Zaretskii
2014-09-12 19:28 ` David Kastrup
2014-09-12 19:59 ` Eli Zaretskii
2014-09-12 13:57 ` David Kastrup
2014-09-12 14:26 ` Eli Zaretskii
2014-09-12 11:38 ` Eric S. Raymond
2014-09-12 13:14 ` Eli Zaretskii
2014-09-12 16:27 ` Eric S. Raymond
2014-09-12 11:46 ` Harald Hanche-Olsen
2014-09-12 13:56 ` Paul Eggert
2014-09-12 15:08 ` Barry Warsaw
2014-09-12 16:16 ` Eric S. Raymond
2014-09-12 6:47 ` Thien-Thi Nguyen
2014-09-12 7:25 ` David Kastrup
2014-09-12 9:34 ` Thien-Thi Nguyen
2014-09-12 8:18 ` Eli Zaretskii
2014-09-12 8:34 ` Eric S. Raymond
2014-09-12 8:40 ` Eric S. Raymond
2014-09-12 11:47 ` Andreas Schwab
2014-09-12 11:57 ` Eric S. Raymond
2014-09-12 12:17 ` David Kastrup
2014-09-12 13:51 ` Andreas Schwab
2014-09-12 15:54 ` Eric S. Raymond
2014-09-12 16:04 ` David Kastrup
2014-09-12 16:18 ` Andreas Schwab
2014-09-12 16:28 ` Eric S. Raymond
2014-09-12 16:43 ` David Kastrup
2014-09-12 20:19 ` resolving ambiguity in action stamps (was: Everyone, please stop making my life more difficult) Joshua Judson Rosen
2014-09-12 20:41 ` Eric S. Raymond
2014-09-12 21:44 ` resolving ambiguity in action stamps Joshua Judson Rosen
2014-09-13 3:45 ` resolving ambiguity in action stamps (was: Everyone, please stop making my life more difficult) Stephen J. Turnbull
2014-09-13 5:35 ` Eric S. Raymond
2014-09-13 6:57 ` Stephen J. Turnbull
2014-09-13 7:26 ` resolving ambiguity in action stamps Harald Hanche-Olsen
2014-09-13 10:50 ` Eric S. Raymond
2014-09-13 12:43 ` Yuri Khan
2014-09-14 7:34 ` Stephen J. Turnbull
2014-09-14 10:55 ` Eric S. Raymond
2014-09-14 11:03 ` David Kastrup
2014-09-14 13:30 ` Stephen J. Turnbull
2014-09-14 14:06 ` David Kastrup
2014-09-14 15:51 ` Stephen J. Turnbull
2014-09-14 14:21 ` Eric S. Raymond
2014-09-14 15:45 ` Stephen J. Turnbull
2014-09-14 15:59 ` David Kastrup
2014-09-14 17:12 ` Eric S. Raymond
2014-09-15 0:09 ` Stephen J. Turnbull
2014-09-13 8:51 ` Andreas Schwab
2014-09-12 14:12 ` Everyone, please stop making my life more difficult Sam Steingold
2014-09-12 14:36 ` David Kastrup
2014-09-12 14:44 ` Yuri Khan
2014-09-12 15:24 ` Sam Steingold
2014-09-12 15:59 ` David Kastrup
2014-09-12 16:12 ` Eric S. Raymond
2014-09-12 17:06 ` Stefan Monnier
2014-09-12 20:35 ` Thien-Thi Nguyen
2014-09-12 15:21 ` Sam Steingold
2014-09-12 15:34 ` Harald Hanche-Olsen
2014-09-12 15:51 ` David Kastrup
2014-09-12 17:44 ` Stephen J. Turnbull
2014-09-12 17:58 ` David Caldwell
2014-09-12 19:19 ` Stephen J. Turnbull
2014-09-12 18:01 ` Harald Hanche-Olsen
2014-09-12 19:36 ` Joshua Judson Rosen
2014-10-28 21:11 ` Randal L. Schwartz
2014-09-12 15:30 ` Phillip Lord
2014-09-12 15:57 ` David Kastrup
2014-09-12 17:10 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140912095542.GD32586@thyrsus.com \
--to=esr@thyrsus.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.