hg push getting worse?

[Andrew John Hughes]

2009/8/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
> 2009/8/11 Maurizio Cimadamore <Maurizio.Cimadamore at sun.com>:
>> Hi
>> I noticed that the time needed for an hg push is getting longer and longer.
>> It used to be quite fast when I started using Mercurial (I normally work
>> with the langtools repository) - now it takes about 5 minutes for a push to
>> go through. I first though this was something that has to do with the amount
>> of changeset in the hg repo - but this doesn't seem to be the case; I also
>> work in the FX compiler and we recently switched to mercurial for FX as well
>> - despite the number of changeset in FX is greater than the one of the
>> langtools repo, FX pushes are really fast (up to 10 seconds).
>>
>> Could it be jcheck that is slowing down pushes - or some other related
>> server-side check?
>>
>> Thanks
>> Maurizio
>>
>
> 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).
>
> 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.
>
> 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...).
>
> Thanks,
> --
> Andrew :-)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>

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.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8