hg push getting worse?
Andrew John Hughes
gnu_andrew at member.fsf.org
Tue Aug 11 13:34:06 PDT 2009
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,
> 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.
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
More information about the web-discuss