Looking ahead: proposed Hg forest consolidation for JDK 10

[Anthony Vanelverdinghe]

Hi

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 [1] 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 
workflows.
During their work to scale Mercurial [2], Facebook contributed/made 
several extensions, such as fsmonitor as mentioned by Joe [3], and the 
ones in their BitBucket repository [4], such as remotefilelog [5].
When working with local clones, the share extension may be helpful [6].
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" [7].

Kind regards,
Anthony

[1] https://hg.mozilla.org/mozilla-central/
[2] 
https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
[3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-October/004990.html
[4] https://bitbucket.org/facebook/hg-experimental
[5] 
https://bitbucket.org/facebook/hg-experimental/src/d2c3a2c02eb6c7e5a7331ba0cf15e5bf7c8dc8dc/remotefilelog/?at=default
[6] https://www.mercurial-scm.org/wiki/ShareExtension
[7] 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.
>
>
>