Harmonize RCS with Monotone

Revision Control with Monotone, Part 1: You might think revision control systems are the province of developers and overcaffeinated technical writers, but admins can put them to good use managing system configuration, too. Here's a look at Monotone, no johnny-one-note when it comes to RCS.

By Carla Schroder | Posted Oct 6, 2004
Page 1 of 2
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

Revision control systems are like, in. Everyone's using one, and you must have strong opinions about why yours is best and the others are toxic waste. If you use Subversion you must dis Arch. If you use Arch you must sneer at Subversion. It is acceptable for both Arch and Subversion users to unite in scorning both CVS and BitKeeper. For some reason, liking more than one is not acceptable.

Monotone is wisely mistrustful of anything that comes from a remote host, so it forces you to set up cryptographic authentication right from the start.
For those of us with actual work to do, a worthy new contender in the revision control fray is Monotone, by Graydon Hoare. Mr. Hoare does things differently than the developers of other revision control systems. He does not engage in public combat over the merits of the various RCS products. He just quietly improves Monotone.

Monotone has a different architecture and a different way of doing things than the others. The current version is 0.14. It has enough rough edges that you should spend some time testing it, and not just dump all of your vitally important projects into it, but already it's impressive. It's a lot simpler to set up and use than CVS, GNU Arch, or Subversion. Some of its features are:

  • Distributed repositories
  • Netsync protocol
  • SQLite backend
  • No hiccups over binary files
  • Direct import of RCS/CVS ,v files

If you prefer a central server/client mode, with strict control of a central server, like CVS or Subversion, Monotone might not be a good fit for you. Monotone is completely decentralized, working in three modes: local working copy, local repository, and netsync server. Each Monotone user is both a client and a server, if they so choose. Of course you can set up a centralized repository, but there's nothing to stop users from going all anarchic and synchronizing directly with each other.

Monotone makes extensive use of SHA1 hashes to create unique identifiers for files, and RSA keys to verify authenticity of network operations. Monotone is wisely mistrustful of anything that comes from a remote host, so it forces you to set up cryptographic authentication right from the start.

Installation

There are a few tricky bits to installation. You can get sources, RPM, .deb, and a Windows .exe from Monotone's home page. For Unix/Linux, you need these dependencies:

You don't have to use Lua if you are an ace programmer or scripter who prefers other languages. Us ordinary mortals are better off following the Monotone instructions as they are written, and they call for Lua.

Debian, as usual, divides packages into microscopic fragments and calls them "lib" -everything. Get all the bits you need at once with this command:

# apt-get install libboost-date-time-dev libboost-filesystem-dev libboost-regex-dev libboost-dev libboost-test-dev libpopt-dev lua50

RPM users need only the boost-devel, popt, and lua packages.

Build-from-sources users, be sure to read the Monotone INSTALL page. You can download and build Monotone in your home directory. For ease of use, be sure that the Monotone directory is in your path, like this example in ~./bashrc, which assumes you use a ~/bin directory:

# set PATH so it includes user's private bin if it exists

if [ -d ~/bin ] ; then
	PATH=~/bin:"${PATH}"
	export PATH
fi

Building A Local Repository

First, create your Monotone database in an existing directory:

$ monotone db init --db=~/project1/project1.db

Next, generate an RSA cryptographic key pair. The author of Monotone recommends using an email address as a key identifier; you may use whatever you like:

$  monotone --db=~/project1/project1.db  genkey carla@mydomain.net
monotone: generating key-pair 'carla@mydomain.net'
enter passphrase for key ID [carla@mydomain.net]:
confirm passphrase for key ID [carla@mydomain.net]:
monotone: storing key-pair 'carla@mydomain.net' in database

Now confirm that the keys were generated by listing them with the "list keys" command"

$ monotone --db=~/project1/project1.db list keys
[public keys]
dd2010598c67d438a8ed9a0b5521b545d0b28f38 carla@mydomain.net
[private keys]
b54b50db61f5032456c8449cb7773ed1068273d9 carla@mydomain.net

Continued on page 2: Adding Files and Watching for Gotchas

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter