RCS in the Key of Monotone
Last week we looked at installing and setting up Monotone, and checked some files into the Monotone database. This week we might as well figure out how to check files out, and how to check out previous versions of a file. Because they're not doing us much good just sitting in there. And we'll move files over a network.
Checking Out Files
$ mkdir sandbox $ cd sandbox
Now you can check out files to work on:
$ monotone --branch=config_files \ --db=~/project1/project1.db checkout . $ ls MT configs
The MT directory contains these files:
$ ls MT manifest options
They are plain text files, created by Monotone. "manifest" keeps track of files:
$ cat MT/manifest d6a0f0a930ce4804a157c87a9ba030026773f429 \ configs/apache-1.3-https 75eed1fe64e66b8695b608369e1516f7395a685b \ configs/postfix-sa
"options" tracks the database and branch:
$ cat MT/options branch config_files database /home/carla/project1/project1.db key
And of course "configs" is the directory and files that were originally checked into the Monotone database. Now you can open and edit any of these files. When you're finished, close and save them, then check them into the database with the "commit" command:
$ monotone commit monotone: committing f22964 ... monotone: committing to branch config_files enter passphrase for key ID [email@example.com]: monotone: committed f22964 ...You'll have the usual changelog entries to make, and Monotone will always ask you for your RSA key passphrase.
Suppose after making several edits and commits, you want to fetch an early revision of a file to look at. How do you find it? Change to your "sandbox" directory, and run this command:
$ monotone log --------------------- Version: f22964a1615 ... Author: firstname.lastname@example.org Date: 2004-03-13T00:28:35 ChangeLog: added virtualhost entries, added ACLs for local subnets --------------------- Version: fe4ef894afb30c76736 ... Author: email@example.com Date: 2004-02-13T00:25:31 ChangeLog: 1st commit of configs for branch office servers
This example shows the first two log entries; the oldest entries are at the bottom. Then you can fetch the specific version by using the SHA1 hash. You only need the first few characters, then Monotone will expand the rest of the string:
$ monotone checkout f2296 subdir monotone: expanded selector 'f2296' -> 'i:f2296' monotone: expanding selection 'f2296' monotone: expanded to 'f22964a1615 ...'The files will be checked into ~/sandbox/subdir, with the same directory structure as "sandbox":
$ ls MT configs subdir $ ls subdir MT configsAs you can see, keeping careful control of where you check in files will save a lot of confusion.
Moving Files Over The Network
One of Monotone's nicest features is the built-in netsync protocol. So there is no additional hassle with setting up networking, it's already there. All you have to do is a public key exchange to get things rolling.
Let's take two users, Cody and Nikita, who wish to exchange Monotone files with each other. First, each user needs to export their public keys to plain text files:
$ monotone --db=/project.db pubkey \ firstname.lastname@example.org > nikita-key.txt $ monotone --db=/project.db pubkey \ email@example.com > cody-key.txt
Then Cody and Nikita exchange their key.txt files, and import them into their Monotone databases. This is how Nikita would do it:
$ monotone --db=/project.db read \ < cody-key.txt monotone: read 1 packet
Then Nikita must write a little Lua script that tells Monotone who to allow read and write access. Call it anything you like, such as sync_permissions:
function get_netsync_read_permitted \ (collection, identity) if (identity == "firstname.lastname@example.org ) \ then return true end return false end function get_netsync_write_permitted \ (collection, identity) if (identity == "email@example.com") \ then return true end return false endCody, of course, must do the same.
Then both Cody and Nikita need to restart Monotone, and tell it to read from the sync_permissions file, and which Monotone branches to make available for synchronization:
$ monotone --db=/project.db \ --rcfile=sync_permissions serve \ tuxcomputing.com config_filesNote that careful naming conventions will ease the whole process. If there are branches under config_files, all of those will be transferred as well. (To see what branches you have, run monotone list branches.)
Finally, to synchronize with Cody, Nikita runs this command:
$ monotone --db=client.db \ sync tuxcomputing.com config_files
The sync command both pushes changes from the client, and pulls changes from the server. If you don't want a two-way synchronization, you may use push or pull in place of sync.
Importing From CVS
You can import a CVS repository if you wish to experiment with migrating from CVS. First, initialize a new Monotone database, then generate the RSA keys. Then import your CVS root, and run a test checkout of the newly imported files:
$ monotone --db=cvsimport.db \ db init $ monotone --db=cvsimport.db \ genkey firstname.lastname@example.org $ monotone --db=cvsimport.db --branch=cvs_import \ /usr/local/cvsroot $ monotone --db=cvsimport.db --branch=checkout \ cvs_import
Installing Monotone's HTML Manual
Monotone comes with a nice HTML manual. To install it, run
$ make html
from your Monotone source directory. You'll need text2html and Texinfo installed on your system for this to work.
What Is Lua?
Lua is a programming language designed to be embedded in other applications, like Monotone.
Monotone is still an infant, so don't depend on it. It might break. You can also expect a lot of changes as it matures, such as commands, command syntax, and features. It does a host of things in addition to what was covered in this short series, such as anonymous server, forks and merges, diffs, and updates. The user manual is pretty good. You can also hang out with Monotone developers and users on the Monotone mailing list, and on IRC, at irc.oftc.net #monotone.