hg push getting worse?

Andrew John Hughes gnu_andrew at member.fsf.org
Tue Aug 11 11:02:07 PDT 2009


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



More information about the jdk7-dev mailing list