hg push getting worse?
John.Coomes at sun.com
Tue Aug 11 12:34:01 PDT 2009
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 :-).
More information about the web-discuss