Jim now decides he will make his base revision available to his employees. To do this first adds a small amount of extra information to his .monotonerc file, permitting Abe and Beth to access his database:
$ cat >>~/.monotonerc function get_netsync_read_permitted (collection, identity) if (identity == "abe@juicebot.co.jp") then return true end if (identity == "beth@juicebot.co.jp") then return true end return false end function get_netsync_write_permitted (collection, identity) if (identity == "abe@juicebot.co.jp") then return true end if (identity == "beth@juicebot.co.jp") then return true end return false end function get_netsync_anonymous_read_permitted (collection) return false end ^D
He then makes sure that his TCP port 5253 is open to incoming connections, adjusting his firewall settings as necessary, and runs the monotone serve command:
$ monotone --db=jim.db serve jim-laptop.juicebot.co.jp jp.co.juicebot.jb7
This command sets up a single listener loop on the host
jim-laptop.juicebot.co.jp
, serving the
jp.co.juicebot.jb7
collection. This collection will naturally
include the jp.co.juicebot.jb7
branch, and any sub-branches.
Now Abe decides he wishes to fetch Jim's code. To do this he issues
the monotone sync
command:
monotone --db=abe.db sync jim-laptop.juicebot.co.jp jp.co.juicebot.jb7 monotone: rebuilding merkle trees for collection jp.co.juicebot.jb7 monotone: connecting to jim-laptop.juicebot.co.jp monotone: [bytes in: 3200] [bytes out: 673] monotone: successful exchange with jim-laptop.juicebot.co.jp
Abe now has, in his database, a copy of everything Jim put in the branch. Therefore Abe can disconnect from the expensive network connection he's on and work locally for a while. When Abe wants to send work back to Jim, or get new work Jim has added, all he needs to do is run the sync command again and work will flow both ways, bringing each party up to date with the work of the other.
At this point Jim is operating as a sort of “central server” for the company. If Jim wants to, he can leave his server running forever, or even put his server on a dedicated computer with better network connectivity. But if Jim is ever unable to play this role of “central server”, perhaps due to a network failure, either Beth or Abe can run the serve command and provide access for the other to sync with. In fact, each employee can run a server if they like, concurrently, to help minimize the risk of service disruption from hardware failures. Changes will flow between servers automatically as clients access them and trade with one another.
In practice, most people like to use at least one central server that is always running; this way, everyone always knows where to go to get the latest changes, and people can push their changes out without first calling their friends and making sure that they have their servers running.