Marek Lukáš via Mercurial <mercurial@mercurial-scm.org> writes: > I found a thread at OpenJDK mailing list with proposal of migrating from > Mercurial to Git: > New candidate JEP: 357: Migrate from Mercurial to Git > https://mail.openjdk.java.net/pipermail/discuss/2019-July/thread.html > Any ideas how to help them continue with Mercurial?
From this: https://mail.openjdk.java.net/pipermail/discuss/2019-July/005096.html > *) There are improvements to Mercurial that can make the conversion > advantages less appealing. For >example, clonebundles that I pointed out multiple times over the year (and >Mark promised to deliver, >at OpenJDK Committers Workshop in February 2019) is still not enabled: >https://bugs.openjdk.java.net/browse/JDK-8211383. Instead, we have >"Alternatives: Keep using >Mercurial" (sic!). > > *) The claim that "There are many more tools for interacting with Git than > Mercurial" look dubious. >For the tools I use from that list: IntelliJ, NetBeans, Atom are supporting >Mercurial as well. It looks like most of the arguments for the move are not based in delivering improvements with the minimal amount of breakage, but rather in moving to git at any cost. I’m not sure how to help with that, except maybe by explicitly offering Aleksey help in improving the situation. The only non-trivially-false argument the JEP gives for moving to git is that the repository could become smaller: > Initial prototypes of converted repositories show a significant > reduction in the size of the version control metadata. For example, > the .git directory of the jdk/jdk repository is approximately 300 MB > with Git and the .hg directory is around 1.2 GB with Mercurial, > depending on the Mercurial version being used. Looking at the .hg/ folder, it seems that there were quite a few big renames which consume additional space in Mercurial, but not in git: $ du -hs .hg/store/data/jdk 382M .hg/store/data/jdk $ LANG=C ls -d jdk ls: cannot access 'jdk': No such file or directory More general: $ for i in .hg/store/data/*; do ls -d ${i##*/} 2>/dev/null 1>/dev/null || echo $i; done | LANG=C xargs du -hsc | LANG=C sort -h | tail -n 8 15M .hg/store/data/corba 30M .hg/store/data/nashorn 48M .hg/store/data/jaxp 51M .hg/store/data/jaxws 66M .hg/store/data/langtools 80M .hg/store/data/hotspot 382M .hg/store/data/jdk 672M total The rename was in 2017: $ LANG=C hg log jdk | head -n 5 changeset: 47216:71c04702a3d5 user: erikj date: Tue Sep 12 19:03:39 2017 +0200 summary: 8187443: Forest Consolidation: Move files to unified layout The solution to that is the RenameSpaceSavingPlan https://www.mercurial-scm.org/wiki/RenameSpaceSavingPlan and going by the bugtracker, that got considerably easier: > Gábor Stefanik 2018-09-21 08:15:18 UTC: > As an alternative to my previous "foreigndelta" proposal, we now have a new > option thanks to the new sparse revlog feature (bug 5480). > With sparse revlogs, it can now be economical to use the same filelog for > multiple files - e.g. not opening a new filelog when a file is > renamed/copied, but instead storing revisions for both filenames in the > pre-existing filelog, or even using a single large filelog (or just a few) > for all files in the repository. In this setup, the pre- and post-rename > revisions end up in the same revlog, so no extension of the delta base field > is required. > > Previously, this would have been uneconomical due to the "delta chain span" > constraint (and before generaldelta, the requirement for deltas to always be > based on the previous revlog entry). Sparse revlogs relax this constraint, so > having unrelated revisions stored in the same revlog file between the > relevant deltas should no longer incur a performance penalty. > - https://bz.mercurial-scm.org/show_bug.cgi?id=883#c45 So the only solid argument for migrating jdk to git is that Mercurial still has additional costs on renaming. Is there an ETA for fixing that — and if not, can one be found? This is basically the one critical feature openjdk would need. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken
signature.asc
Description: PGP signature
_______________________________________________ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial
