hg push getting worse?

[Andrew John Hughes]

2009/8/11 John Coomes <John.Coomes at sun.com>:
> Andrew John Hughes (gnu_andrew at member.fsf.org) wrote:
>> 2009/8/11 John Coomes <John.Coomes at sun.com>:
>> > 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.
>>
>> True.  It's hard to tell from the client side as hg appears to hang
>> 'searching for changes' and then suddenly a burst of information
>> appears, either reporting success or failure.  I presume this is part
>> of the design of hg unfortunately, but it would be helpful if things
>> were more verbose.  I presume hooks were never meant to utilise enough
>> time that this would become an issue.
>>
>> I can see how zfs snapshotting would take longer over time.  Although
>> the snapshots are, I presume, relative to the last so that the size
>> remains fairly sane, the sheer number of them is likely to cause a
>> slowdown. Is there a significant benefit to creating these?
>
> I don't know the openjdk infrastructure, so am just guessing,

Same here.

 but I
> suspect there are only a finite number of snapshots maintained.  The
> benefit is being able to recover :-).  AFAIK, we've only used it once
> or twice, but having the snapshots made it possible.
>

Ah, sounds worth it then ;)

>> ...                                                          And are
>> they also created in Maurizio's FX project?
>
> I have no idea.
>
>> >> > 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.
>> >
>>
>> Is there any further news on whether the forest extension will become
>> a standard part of Mercurial? When I went searching for a client-side
>> version to support newer versions, I had to resort to using a snapshot
>> of their repository for forest.
>
> I doubt forest will ever become part of mercurial.  Mercurial now has
> an experimental sub-repo feature for dealing with nested repositories.
> It doesn't have the flexibility of the forest extension, so wouldn't
> work for openjdk, at least as it stands now.
>
>> ...
>> All changes have to be approved first, so could not this issue be
>> flagged at that point?  The history could also be scanned for
>> duplicates at that point if someone really wanted to be sure.  The
>> case is even worse with the whitespace checks.  Given jcheck clearly
>> can find the issues, can it not also fix them?  Or could some of these
>> checks be applied on the client-side? Worst case, could the whole
>> repo. not just be sanitised on a regular basis?  As is, you push a
>> commit, wait several minutes and then get a result from jcheck saying
>> there is an extra space at the end of one line.  So, you have to
>> rollback the commit, remove the space, reapply the commit with the
>> same comments and then push again.  In all, a lot of time is spent for
>> very little gain.
>
> I think the problem is access to jcheck.  I'm not sure why it isn't
> available externally.  We run jcheck on our local repos before
> pushing, and it's reasonably convenient.  Or maybe I should say not
> too inconvenient :-).
>

Exactly.  Now I know about them (through failed changesets), I could
probably come up with my own checks for the whitespace issues I
mentioned, but I have no idea what other checks may be being performed
by jcheck.  It's a black box, and our only evidence of its behaviour
is by testing with our changesets as input.

> -John
>
>



-- 
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