hg push getting worse?

[John Coomes]

Andrew John Hughes (gnu_andrew at member.fsf.org) wrote:
> > ...
> > From my experience with the OpenJDK servers, I think it may be jcheck.
> > Â Unfortunately, jcheck itself is not Free Software, so it is
> > impossible for me to say for definite. Â Instead, we seem to be
> > discovering what checks it performs only when failures occur.
> > 
> > I do know it does the following:
> >
> > * Checks the use of whitespace in changesets, rejecting the use of
> > tabs and trailing whitespace.
> > * Checks the format of the commit message. Â It must even follow the
> > bugid/summary/reviewer format documented in the developer guide or
> > simply be 'Merge'.
> > * Checks that the bugid used is not used by any other changeset.
> >
> > I've run into all of these with different changesets. Â I can
> > definitely see how the latter could take a while on something like the
> > jdk repository (which dwarfs the others in size).

I think jcheck is relatively light-weight compared to the zfs snapshot
and auto-push that are also done.  But it would be nice to know for
sure.

> > jcheck appears to perform its check on the changeset once committed to
> > the remote repository and then performs a rollback if it fails,
> > although you don't see any of this feedback in realtime on the client.
> > Â I presume this also means it has to get Mercurial to generate the
> > changeset (and others for the bugid check) which would take time.

That's the standard way that mercurial hooks work, and the reason we
have the extra *-gate forests.  In more recent versions of mercurial,
the pending changesets aren't visible until the hooks have completed
successfully, so the *-gate forests become unnecessary.  We haven't
been able to update because the server-side of the forest extension
doesn't work w/recent mercurial releases.

> > It would be much better if we could perform these sanity checks
> > locally, though we'd still need some way of checking this had been
> > done on the server side (or who knows, we could trust the developers
> > to have done it...).
> 
> I should also note that duplicate bugids can appear completely
> legitimately in certain merge cases.  This is the current issue with
> updating OpenJDK6's HotSpot..  Fixes for bugs occur both in the
> original (rebased) OpenJDK6 HotSpot and the copy of HotSpot being
> merged from the hs14 repository, resulting in duplicate bugids which
> jcheck rejects.  I presume this is to protect against the case that
> someone mistypes the bugid as another legitimate bugid, but it is
> certainly an expensive check for what seems a fairly unlikely
> occurrence.

The goal is to prevent people from checking in fixes piece-meal,
scattering a bug fix over 2, 3 or more changesets.  Having a bug fix
isolated to a single changeset makes backporting it to a different
release much, much easier.  We lived with the practice of partial
fixes for quite some time, and I'd rather not go back.

-John