Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Mercurial 3.4 RC Testing

63 views
Skip to first unread message

Gregory Szorc

unread,
Apr 17, 2015, 1:33:51 PM4/17/15
to dev-versi...@lists.mozilla.org
The first release candidate for the next major release of Mercurial - 3.4 -
was released today. According to Mercurial's time-based release plan, 3.4
will be released on May 1. Per Mozilla's release policy, we'll upgrade
hg.mozilla.org to 3.4.x on or around June 1.

I'm writing this email to ask people to download the RC from
http://mercurial.selenic.com/release/mercurial-3.4-rc.tar.gz and to test it
locally. Regressions are treated very seriously and will block the final
3.4 release. If you find any regressions, please file a bug at
http://bz.selenic.com/ or ping me and I'll help you.

3.4 has a ton of changes. A comprehensive list can be found at
http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_3.4-rc_.282015-04-17.29.
Upgrade notes are available at
http://mercurial.selenic.com/wiki/UpgradeNotes#A3.4:_minor_changes.

3.4 contains a ton of performance work. This is mostly driven by Facebook
and Google optimizing Mercurial for repositories larger than
mozilla-central.

Some highlights:

* The new wire protocol - bundle2 - is now enabled by default on the
server. (Clients still need to enable it.) This wire protocol uses fewer
server round trips (read: faster pushing and pulling) and push and pull
operations become atomic (before, things like bookmarks were applied after
changesets were sent). This protocol also enables peers to exchange custom
metadata as part of the exchange. There's lots of potential for awesome
features. Facebook has already shown how you can have the server rebase on
push. This is probably the most important new feature in Mercurial 3.4.
* The tags cache has been rewritten and performance issues causing local
slowness with evolve users on large repositories (such as mozilla-central)
and server performance (such as on Try) have been resolved.
* hgweb (the HTTP/HTML interface) now has JSON output for nearly every API.
e.g. URLs like https://hg.mozilla.org/mozilla-central/json-rev/d0a6539a1ca8
(doesn't work yet) will return JSON. This should enable people to build
more services against Mercurial servers without having to clone entire
repos. It also opens the door for more XHR in the web interface.
* The "histedit.defaultrev" config option can be used to define a default
revset for histedit.
* The "histedit.linelen" option can be used to overwrite the default 80
character max width in histedit's interactive view
* Many optimizations were made around obsolescence markers. Users of evolve
should have a significantly faster experience.
* hgweb commands are now documented via `hg help hgweb`.
* When using Mercurial with Python 2.7.9, the system's CA cert bundle
should be used automatically.
* Extensions can now add extra data to per-changeset URLs in hgweb. Expect
some coolness when this rolls out on hg.mozilla.org :)
* If you type an unknown command into Mercurial, Mercurial will suggest
other commands based on string similarity.
* Google implemented lots of fancy code around manifest reading. Operations
like `hg export tip` on mozilla-central are now ~50% faster.
* `hg import` now has --bypass to allow patches to be imported without
touching the working directory
* Functionality related to `hg record` has been moved from an official
extension into the core. You still need to enable the extension to get `hg
record`, but other commands can now easily add interactive functionality.
* `hg commit --interactive` is now a thing.
* `hg revert --interactive` is also now a thing.
* An experimental curses record/interactive interface has been added.
Enable via "experimental.crecord = true"
* A "censor" command can be used to "censor" data from previous commits. If
you accidentally commit something you shouldn't have, there is now an
option to ensure future clients don't clone this data forever. I believe
this feature is still somewhat experimental.
* The "revbranchcache" added in 3.3 received some performance improvements.
The old behavior made first-run experience on large repos like
mozilla-central pretty bad.
* Google is implementing a new storage backend for manifests (lists of
files in the commit). Experimental support has been added. This will
eventually lead to Mercurial supporting narrow clone (cloning only certain
directories). This will eventually enable us to do things like consider
merging the l10n repos into mozilla-central.
* `hg diff --root` can produce diffs relative to a specified directory.
Useful for submitting patches to "vendored" 3rd party projects that exist
in your repo.
* Phases computation is now implemented in C, leading to faster performance.
* Performance of `hg revert` is now 4x faster in some scenarios.
* Performance of `hg status` without hgwatchman on OS X is about 25% faster
(you should be using hgwatchman)
* `hg shelve --interactive` is now a thing.
* hgk can now display obsolete changesets.
* `hg diff` appears to be ~20% faster.
* Performance of `hg status` on case insensitive filesystems is now faster.
* Extensions can now implement custom histedit actions.
* This will be the final release of Mercurial to support Python 2.4 and 2.5.

When you upgrade to 3.4, some one-time upgrades of internal files may
occur. This could take up to a few minutes. If you notice a long pause
after upgrade, hold off reporting the bug unless it is reproducible.

Please test and report feedback!

Steve Fink

unread,
Apr 17, 2015, 2:32:39 PM4/17/15
to Gregory Szorc, dev-versi...@lists.mozilla.org
The first thing I ran into is that I needed to upgrade hgwatchman or I
would get a very long stack for an "expected string or buffer" error that
was not obviously connected to hgwatchman. (The stack went through several
extensions both before and after hgwatchman.)
> _______________________________________________
> dev-version-control mailing list
> dev-versi...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-version-control
>

Gregory Szorc

unread,
Apr 17, 2015, 3:22:15 PM4/17/15
to Steve Fink, dev-versi...@lists.mozilla.org, Gregory Szorc
Yeah, that's a problem with upgrades sometimes. 3.4 was a massive release
and a lot of internal APIs changed. With monkeypatching, it's hard to
attribute a crash to a specific extension :/

You need to be running the latest version of watchman and evolve for 3.4
compatibility. Having the latest version-control-tools is also a good idea.
0 new messages