hg push getting worse?

[John Coomes]

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

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

-John