With Jim’s server preparations done, now Abe is ready to fetch Jim’s
code. To do this he issues the monotone
$ mtn --db=abe.mtn sync "mtn://jim-laptop.juicebot.co.jp?jp.co.juicebot.jb7*" mtn: connecting to mtn://jim-laptop.juicebot.co.jp mtn: first time connecting to server mtn://jim-laptop.juicebot.co.jp mtn: I'll assume it's really them, but you might want to double-check mtn: their key's fingerprint: 9e9e9ef1d515ad58bfaa5cf282b4a872d8fda00c mtn: warning: saving public key for firstname.lastname@example.org to database mtn: finding items to synchronize: mtn: bytes in | bytes out | revs in | revs out | revs written mtn: 2587 | 1025 | 1 | 0 | 1 mtn: successful exchange with mtn://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. Remember that, in monotone, work is done between workspaces in the filesystem and the local database; network connectivity is necessary only when that work is to be shared with others.
As we follow the juicebot team through the next several steps, we’ll see
them run the
sync command again with Jim, and work will flow
both ways. The first time you
sync a new database, monotone
remembers the server and branch patterns you use, and makes them the
default for future operations.
At the end of each exchange, information about all changes in the branch known to each database have been sent to the other party - including the work of the third team member that had previously been exchanged. As well as allowing each team member to learn about the others’ work, this also means that each party’s laptop contains a backup of the others’ work too.
Jim, Abe and Beth will continue working like this while they’re getting started, and we’ll revisit the issue of network service with them a little later as the project grows.