Next: , Previous: Adding Files, Up: Tutorial


2.7 Committing Work

Satisfied with the work he's done, Jim wants to save his changes. He then commits his workspace, which causes monotone to process the _MTN/revision file and record the file contents, manifest, and revision into the database. Since he provided a branch name when he ran setup, monotone will use this as the default branch name when he commits.

     $ mtn commit --message="initial checkin of project"
     mtn: beginning commit on branch 'jp.co.juicebot.jb7'
     mtn: committed revision 2e24d49a48adf9acf3a1b6391a080008cbef9c21

When monotone committed Jim's revision, it updated _MTN/revision to record the workspace's new base revision ID. Jim can use this revision ID in the future, as an argument to the checkout command, if he wishes to return to this revision:

     $ mtn automate get_base_revision_id
     2e24d49a48adf9acf3a1b6391a080008cbef9c21

Monotone also generated a number of certificates attached to the new revision, and made sure that the database contained a copy of Jim's public key. These certs store metadata about the commit. Jim can ask monotone for a list of certs on this revision.

     $ mtn ls certs 2e24d49a48adf9acf3a1b6391a080008cbef9c21
     -----------------------------------------------------------------
     Key   : jim@juicebot.co.jp (398cb10d...)
     Sig   : ok
     Name  : branch
     Value : jp.co.juicebot.jb7
     -----------------------------------------------------------------
     Key   : jim@juicebot.co.jp (398cb10d...)
     Sig   : ok
     Name  : date
     Value : 2004-10-26T02:53:08
     -----------------------------------------------------------------
     Key   : jim@juicebot.co.jp (398cb10d...)
     Sig   : ok
     Name  : author
     Value : jim@juicebot.co.jp
     -----------------------------------------------------------------
     Key   : jim@juicebot.co.jp (398cb10d...)
     Sig   : ok
     Name  : changelog
     Value : initial checkin of project

The output of this command has a block for each cert found. Each block has 4 significant pieces of information. The first indicates the signer of the cert, in this case jim@juicebot.co.jp. The second indicates whether this cert is “ok”, meaning whether the rsa signature provided is correct for the cert data. The third is the cert name, and the fourth is the cert value. This list shows us that monotone has confirmed that, according to jim@juicebot.co.jp, the revision 2e24d49a48adf9acf3a1b6391a080008cbef9c21 is a member of the branch jp.co.juicebot.jb7, written by jim@juicebot.co.jp, with the given date and changelog.

It is important to keep in mind that revisions are not “in” or “out” of a branch in any global sense, nor are any of these cert values true or false in any global sense. Each cert indicates that some person – in this case Jim – would like to associate a revision with some value; it is up to you to decide if you want to accept that association.

Jim can now check the status of his branch using the “heads” command, which lists all the head revisions in the branch:

     $ mtn heads
     branch 'jp.co.juicebot.jb7' is currently merged:
     2e24d49a48adf9acf3a1b6391a080008cbef9c21 jim@juicebot.co.jp 2004-10-26T02:53:08

The output of this command tells us that there is only one current “head” revision in the branch jp.co.juicebot.jb7, and it is the revision Jim just committed. A head revision is one without any descendants. Since Jim has not committed any changes to this revision yet, it has no descendants.