Development

Mercurial 3.5

Version 3.5 of the Mercurial revision-control system was released on July 31, bringing with it a handful of interesting new features, such as a new wire protocol and an extensible data-exchange format.

The Mercurial project makes quarterly releases and, like many projects that adhere to a regular schedule, each new release may only usher in a few improvements. But that does not mean that progress has slowed down or that there is waning interest—Git may attract a larger share of the revision-control-system press, but Mercurial is used by some rather large free-software projects, including Mozilla and Python (at least for the present, where Python is concerned).

The 3.5 release debuts a new wire protocol called "bundle2." This is the protocol used to transfer data when doing push, pull, and related operations. Bundle2 was first made available in the 3.4 release, but was only enabled by default for servers—thus allowing for a measure of testing before widespread deployment. The 3.5 release activates bundle2 for clients, too. Furthermore, both the old and new protocols are still supported on the client and server side, so the update will opportunistically use bundle2 when available, but will not leave older systems stranded.

Although the previous protocol served Mercurial well for many releases, it was hampered by some rather striking design limitations. The most prominent was that a separate API call was used for each chunk of data transferred (e.g., each updated file). Thus, neither pushes nor pulls were atomic operations, which led to any number of race conditions and, no doubt, frustrating failure modes. With bundle2, all of the data for a given operation is transferred in one chunk, allowing operations to succeed or fail atomically.

Another user-visible feature of bundle2 is that it supports transferring a repository's cache of tags from the server to the client whenever a client performs a pull or clone. In previous releases, the client would have to recompute the tags which, for large repositories, obviously took unwanted excess time.

Bundle2 also allows Mercurial extensions to support custom additions to the data stream used for each operation. Additional parts (such as metadata) can be inserted into the payload stream for standard push and pull operations—whereas, in previous releases, such additions would need to be transported using separate requests.

Speaking of extensions, the progress extension has been merged into the core codebase and enabled by default. A popular extension in previous releases, it draws progress bars to report on in-progress operations.

A significant functional addition to Mercurial in this release is the "auto share" feature, which was contributed by Mozilla's Gregory Szorc. Auto share allows a developer to clone multiple branches of the same repository and have them automatically share the same backing storage. Mercurial will detect that a new clone operation is using the same remote as an existing one and (if configured to use auto share) pull down only the changesets unique to the new fork. Szorc notes that this feature was designed with automated tools like continuous-integration systems in mind, but that it can significantly reduce disk usage for developers as well.

Among the other changes is the addition of include and subinclude directives for hgignore files. This allows the contents of a directory-specific hgignore file to be referenced by the hgignore file in a parent directory—meaning that the parent directory no longer needs to include an exhaustive list of files to ignore. The result is that directories can be more easily rearranged and automatically preserve hgignore rules.

As one would expect, there are many additional changes in the new release beyond those described here. Work progresses on a number of fronts, such as splitting the content manifests for a repository (which map contents to files) from a single, monolithic manifest-per-repository model to a per-directory model.

Finally, the new release officially drops support for Python 2.4 and 2.5. While there were, no doubt, few users still running each of those releases, dropping them signifies that a cleanup effort is making steady progress—one whose ultimate goals may include adding Python 3 support. Whether that Python 3 support ever arrives remains to be seen, of course.

It can be easy to be accidentally Git-centric in one's views of the free-software community and that community's development trends. The new Mercurial release shows that, despite all of the ups and downs in the revision-control wars, there remains a competitive landscape.

Comments (none posted)

Quote of the week

— Ole Tange presents the results of some covert, real-world research.

Comments (2 posted)

A leadership change at FFmpeg

FFmpeg leader Michael Niedermayer has announced his departure from the project. "I hope my resignation will make it easier for the teams to find back together and avoid a more complete split which would otherwise be the result sooner or later as the trees diverge and merging all improvements becomes too difficult for me to do."

Comments (138 posted)

LibreOffice 5.0 released

The LibreOffice 5.0 release is out. "LibreOffice 5.0 sports a significantly improved user interface, with a better management of the screen space and a cleaner look. In addition, it offers better interoperability with office suites such as Microsoft Office and Apple iWork, thanks to new and improved filters to handle non standard formats." See this post from Michael Meeks for a detailed description of the work that went into this release.

Full Story (comments: 27)

Development newsletters from the past week

• What's cooking in git.git (August 3)
• Git Rev News (August 5)
• LLVM Weekly (August 3)
• OCaml Weekly News (August 4)
• OpenStack Community Weekly Newsletter (July 31)
• Perl Weekly (August 3)
• PostgreSQL Weekly News (August 2)
• Python Weekly (July 30)
• This Week In Rust (August 3)
• Ruby Weekly (July 30)
• Wikimedia Tech News (August 3)

Comments (none posted)

OpenSSL: License Agreements and Changes Are Coming

At the OpenSSL blog, Rich Salz has announced the project's decision to migrate away from the "rather unique and idiosyncratic" OpenSSL license to the Apache 2.0 license. In order to make the change in an upcoming release, though, the project "will soon require almost every contributor to have a signed a Contributor License Agreement (CLA) on file." Individual and corporate versions of the CLA are posted; trivial patches will evidently not trigger the need for the submitter to sign and file an agreement. Salz closes by noting that more details are still to come, since "there is a lot of grunt work needed to clean up the backlog and untangle all the years of work from the time when nobody paid much attention to this sort of detail."

Comments (34 posted)

Mozilla criticizes browser-selection change in Windows

Mozilla has launched a multi-pronged campaign to challenge a recent change in Windows that has the effect of overriding users' choice of Firefox as the default web browser. Mozilla CEO Chris Beard posted a blog entry outlining the problem as well as an open letter to Microsoft CEO Satya Nadella. The change apparently landed with the recent Windows 10 release and, as Beard explains it, "while it is technically possible for people to preserve their previous settings and defaults, the design of the new Windows 10 upgrade experience and user interface does not make this obvious nor easy." Mozilla has also posted tutorials and videos to help users restore Firefox as their default browser.

Comments (28 posted)