emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Everyone, please stop making my life more difficult


From: Eric S. Raymond
Subject: Re: Everyone, please stop making my life more difficult
Date: Fri, 12 Sep 2014 05:55:43 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

Eli Zaretskii <address@hidden>:
> > 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) "address@hidden" 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:address@hidden (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:address@hidden
> 
> 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>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]