|Developer(s)||The monotone team|
|Initial release||April 6, 2003|
1.1 / May 4, 2014
|Operating system||Unix, Linux, BSD, Mac OS X, Windows|
|Available in||English, Italian, Swedish, Portuguese, German, Spanish|
|License||GNU General Public License|
Monotone tracks revisions to files, groups sets of revisions into changesets, and tracks history across renames. The focus of the project is on integrity over performance. Monotone is designed for distributed operation, and makes heavy use of cryptographic primitives to track file revisions (via the SHA-1 secure hash) and to authenticate user actions (via RSA cryptographic signatures).
Like GNU arch, and unlike Subversion, Monotone takes a distributed approach to version control. Monotone uses SHA-1 hashes to identify specific files or groups of files, as with Git and Mercurial, in place of linear revision numbers. Each participant maintains their own revision history, stored in a local SQLite database.
Prior to some heavy optimisation in revision 0.27, Monotone's emphasis on correctness over optimisation was often blamed for poor initial experiences. The first action of a new user is often to synchronize (clone) a large existing Monotone database, an action which often took hours for large databases, due to the extensive validation and integrity checking which Monotone performs when revisions are moved through the network. Once the initial (clone) database is populated, subsequent actions usually proceed more rapidly. As of July 2010[update], there is still room for further optimisation on some rarer functions.
Monotone is especially strong in its support for a diverge/merge workflow, which it achieves in part by always allowing commit before merge.
Although Monotone originally supported a variety of networking protocols for synchronizing trees, it now exclusively uses a custom protocol called netsync, which is more robust and efficient, and shares some conceptual ground with rsync and cvsup. (However, as of version 0.27, it is possible to use the netsync protocol over any stream, notably including ssh connections.) Netsync has its own IANA-assigned port (4691) and older versions of it are supported by a Wireshark plug-in for traffic analysis. There is no separate Monotone server because any Monotone client can act as a server.
Other features of Monotone include:
- Good support for internationalization and localization
- Portable design, implemented in C++
- High integrity is a key design goal
- Monotone can import CVS projects.
- Signing of revisions using RSA certificates
- Easy to learn, due to a command set similar to that of CVS
- Very good at branching (both divergences within a branch and named branches) and merging
- Good documentation
- Very low maintenance
- Stable graphical user interfaces exist:
- guitone, a Qt-frontend to manage workspaces and databases (supported on MS-Windows and Unix/Linux/MacOS)
- mtn-browse, a Gtk2 graphical browser that lets you browse the database, even remotely, without the need for a workspace (supported on Unix/Linux/MacOS)
- Monotone-Viz, a revision history grapher (supported on MS-Windows and Unix/Linux)
- TracMtn, a Trac plugin for history and repository browsing
- Complete and comprehensive Perl library that allows you to completely control Monotone from a Perl script (mtn-browse makes use of this)
As of January 2008[update], possible drawbacks of Monotone include:
- Potential users cannot check out (or commit) from behind a proxy (very common in corporate environments) due to non-http protocol.
- Performance issues for certain operations (most noticeable initial pull)
Monotone version 0.26 introduced major changes to the internal database structures, including a new structure known by Monotone developers as a roster. Monotone databases created with version 0.26 can not exchange revisions with older Monotone databases. Older databases must first be upgraded to the new format. The new netsync protocol is incompatible with earlier versions of Monotone.
Monotone is implemented in modern-dialect C++ on top of the Boost library, the Botan cryptography library, and the SQLite database library. Monotone supports customization and extension via hook functions written in the Lua programming language. The monotone build process is automated with BuildBot and includes extensive regression tests.
Monotone as Git inspirationEdit
In April 2005, Monotone became the subject of increased interest in the FOSS community after Linus Torvalds mentioned it as a possible replacement for BitKeeper in the Linux development process. In a post on the Linux kernel mailing list, Torvalds praised Monotone and disparaged Subversion (and by extension, all client-server version-control systems):
Don't bother telling me about subversion. If you must, start reading up on "monotone". That seems to be the most viable alternative, but don't pester the developers so much that they don't get any work done. They are already aware of my problems ;)
Instead of adopting Monotone, Torvalds decided to write his own SCM system, Git. Git's design uses some ideas from Monotone, but the two projects do not share any core source code. Git has a much stronger focus on high performance, inspired by the lengthy history and demanding distributed modes of collaboration used by Torvalds and the other Linux kernel authors. Torvalds later commented on Monotone's design and performance:
If you want a VCS that is written in C++, go play with Monotone. Really. They use a "real database". They use "nice object-oriented libraries". They use "nice C++ abstractions". And quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess.
A key issue debated was whether the replacement of BitKeeper should support cherry picking, whereby a tree maintainer can approve a subset of patches while rejecting others on an individual basis. Torvalds argued that this approach "results in the wrong dynamics and psychology in the system" by shifting burden to the upstream maintainers rather than forcing downstream maintainers to put more effort into keeping their trees free from garbage. He further argued that Monotone is correct in its aversion to cherry-picking as a feature, but then failed to take it far enough by not making it easy enough to "throw away" unclean working trees after their purpose is served. Torvalds also noted his perception that Monotone at that time had not achieved the performance level required by a project as large as Linux kernel development.
This argument runs contrary to the perception among many[weasel words] software developers that cherry picking is an advanced feature that an SCM tool should strive to support. Other SCM tools, such as Darcs, are particularly strong in this area. As of 2010[update], both Git and Monotone have supported cherry picking for some time.
- "NEWS". May 4, 2014. Retrieved July 16, 2019.
- "7 Version Control Systems Reviewed". September 18, 2008. Retrieved 2010-11-01.
- "Dealing with a Fork - monotone documentation". Retrieved 2010-11-21.
- What are rosters
- Linus Torvalds (April 6, 2005). "LKML: Linus Torvalds: Kernel SCM saga". LKML.
- Linus Torvalds (2007-09-06). "Re: [RFC] Convert builin-mailinfo.c to use The Better String Library". GMANE. Archived from the original on 2016-02-06.
- David Woodhouse (2005-04-07). "LKML: David Woodhouse: Kernel SCM saga". Retrieved 2017-02-23.
- Linus Torvalds (April 7, 2005). "LKML: Linus Torvalds: Re: Kernel SCM saga". LKML.