Friday, April 22, 2005

Using monotone for distributed ROMS development

Here is how it is done. First get monotone, I would suggest getting one of the compiled binaries, since compiling does not appear to be trivial. Read on for an example of how to use this program to link to a ROMS project. This tutorial is based heavily on the turorial available on the monotone site.


First, lets create a 'vanilla' ROMS database (from 'roms-2.1.tar.tz' already in our home directory):

monotone db init --db=~/roms.db
monotone setup roms
cd roms
tar xvfz ~/roms-2.1.tar.gz
monotone add roms-2.1/


Before we commit, we need to create an identiy for ourselves:

monotone --db=~/roms.db genkey hetland@tamu.edu


Now, commit the initial files to the database with a checkin:

monotone --branch=edu.tamu.rocks.roms.roms-2.1 commit --message='Initial checkin of ROMS'


Now, you will want to be able to distribute your public key, so lets get it out of the database:

monotone --db=~/roms.db pubkey hetland@tamu.edu > ~/hetland.roms.pubkey



Shared access Suppose I want to give someone (say, user rich@usgs.guv) access to this code, and allow them to make and submit changes. Rich will need to create a data base, and a public/private key pair on his machine:

usgs:~$ monotone db init --db=roms.db
monotone --db=~/roms.db pubkey rich@usgs.guv > ~/rich.roms.pubkey


Rich and I then both exchange keys, and read them into our database files. For example, Rich would do this:

usgs:~$ monotone --db=~/roms.db read < hetland.roms.pubkey


I also add Rich's key. And, if I am to host the server, I need to allow Rich access through the .monotonerc file:

monotone --db=~/roms.db read < rich.roms.pubkey
cat >>~/.monotonerc
function get_netsync_read_permitted (collection, identity)
if (identity == "rich@usgs.guv") then return true end
return false
end

function get_netsync_write_permitted (collection, identity)
if (identity == "rich@usgs.guv") then return true end
return false
end
^D

Obviously, I need to add a separate line for each user (and echange public keys and read them into the database).

Now, I start the server for this database and branch:

monotone --db=~/roms.db serve rocks.tamu.edu edu.tamu.rocks.roms.roms-2.1


Rich can now access this using the command

usgs:~$ monotone --db=~/roms.db sync rocks.tamu.edu edu.tamu.rocks.roms.roms-2.1
usgs:~$ monotone --db=~/roms.db --branch edu.tamu.rocks.roms.roms-2.1 checkout roms

This gets the information from my computer and puts it in the database roms.db. The second command then takes the information from this database and extracts the files into the subdirectory roms. If Rich makes changes, and wants to include them in the distribution, he would type:

usgs:~/roms$ monotone --db=~/roms.db commit
usgs:~/roms$ monotone --db=~/roms.db sync


Anonymous access Now, to allow someone less trusted (say, hernan@rutgers) anonymous access to my code, which will allow reads but not writes, I will set up anonymous access. First I need to add that to the .monotonerc file:

cat >>~/.monotonerc
function get_netsync_anonymous_read_permitted (collection)
return true
end
^D


Now Hernan must simply create a database, include my public key, pull the data over the network, and extract the files from the database:

rutgers:~$ monotone init db --db=~/roms.db
rutgers:~$ monotone --db=~/roms.db read < hetland.roms.pubkey
rutgers:~$ monotone --db=~/roms.db pull rocks.tamu.edu edu.tamu.rocks.roms.roms-2.1
rutgers:~$ monotone --db=~/roms.db --branch edu.tamu.rocks.roms.roms-2.1 checkout roms

Again, this exteacts the code into the roms subdirectory. Hernan now has an up-to-date copy of ROMS, but cannot upload any changes he makes.

No comments:

Post a Comment