Looking ahead: proposed Hg forest consolidation for JDK 10
goetz.lindenmaier at sap.com
Mon Oct 17 10:10:27 UTC 2016
Hi Anthony and Joe,
> such as hg rebase, hg histedit, hg graft, hg strip, hg strip --keep, and hg commit --amend" .
I understand how these commands replace hg queues.
I don't understand how they replace having several
clones to do something like this:
- Change 1 is compiling (in clone 1)
- Debugging change 2 (in clone 2)
- I get a review and want to immediately edit change 3 (in clone 3), without
invalidating the sources I stepped in the debugging session and without
canceling the builds.
If I use a single clone, I can have these three changes in three branches,
or in several sequential changes (like a mercurial queue) I keep reordering with
histedit. But as there is only one source tree I can only work on one of
the changes at a time.
Hg share will do this job I assume.
I have been looking at the consol-proto:
hg clone takes 30 minutes. Before, get_source.sh took 20 mins.
Hg share takes 5 minutes. Before, hg clone of hotspot took 3 mins.
Hg diff takes 32 secs!!!, before it took 4 secs on hotspot repo.
The full repo requires 1.9G.
A 'hg share' repo requires 0.6G
A hotspot repo before required 0.2G.
I will be able to live with this using modern, slower functionality ;)
But it imposes a considerable overhead in hardware, tool runtime
and administration on my side.
Can I check out several
> -----Original Message-----
> From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of
> Anthony Vanelverdinghe
> Sent: Freitag, 14. Oktober 2016 22:11
> To: jdk9-dev at openjdk.java.net
> Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK 10
> While I'm not an OpenJDK committer (yet, hope to become so one fine
> day), I believe this is a great initiative. Since several people have
> raised concerns related to the increased repository size, I just wanted
> to point out that both Facebook and Mozilla work with Mercurial
> repositories which dwarf a typical OpenJDK repository. For example, a
> clone of mozilla-central  is 2.79 GB, whereas a clone of jdk9-dev is
> less than 1 GB.
> There are also several Mercurial extensions which may prove to be useful
> for people having to work with large repositories and/or adapt their
> During their work to scale Mercurial , Facebook contributed/made
> several extensions, such as fsmonitor as mentioned by Joe , and the
> ones in their BitBucket repository , such as remotefilelog .
> When working with local clones, the share extension may be helpful .
> Finally, note that mq is "often considered for deprecation", so this may
> be an opportunity to adopt "modern tools, such as hg rebase, hg
> histedit, hg graft, hg strip, hg strip --keep, and hg commit --amend" .
> Kind regards,
>  https://hg.mozilla.org/mozilla-central/
>  http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-
>  https://bitbucket.org/facebook/hg-experimental
>  https://www.mercurial-scm.org/wiki/ShareExtension
>  https://www.mercurial-scm.org/wiki/MqExtension
> On 14/10/2016 19:03, Brian Goetz wrote:
> >> Conversely, I think it is reasonable for engineers making changes to
> >> the JDK to be wiling to offer some flexibility in adjusting
> >> established worksflows optimized for the split repositories to
> >> accommodate the sort of infrastructure changes being proposed here
> >> for a consolidated one.
> > Let me amplify this: OpenJDK developers are not the only stakeholders
> > here. By aligning more with the way the rest of the world develops
> > -- all code in one linearized, transactionally updated repo -- it
> > increases the feasibility / reduces the cost of tools like 'bisect' to
> > determine where a fault was introduced. This reduces SQE costs and
> > increases product quality -- something we all have a stake in. David
> > Lloyd has pointed up other tooling-related benefits, such as making it
> > easier to maintain a git mirror.
> > Most of the objections raised so far have been "(I think they will)
> > make my life harder." Fair enough; people should be their own
> > advocates. But let's not forget the significant benefits that accrue
> > to *everyone* as a result, and keep those in mind when judging the
> > pros and cons.
More information about the jdk9-dev