Using Montone for Pidgin

​Monotone is a distributed version control system, and as such has some user-visible differences compared to, say, CVS or SVN. In addition, each of the existing DVCS solutions seem to have idiosyncrasies to themselves, and monotone is no exception. Due to these things, we'll try to grow some monotone howtos and best practices on this page.

External Documentation

• The ​official manual
• The ​monotone wiki has a lot of good information, as well

Getting Started with Pidgin monotone

There is currently an experimental monotone server running on pidgin.im, which fetches nightly changes from Gaim SVN (by way of ​tailor). We may or may not keep this history going forward; for now the server is read-only, and intended to be simply a point for people to start playing. Note that the read-only server does not mean you cannot commit -- this is one of the beautiful things about a DVCS.

To fetch the revision history from this server, and check out a working copy, do:

  $ DATABASE=/home/user/monotone_databases/gaim.mtn
  $ WORKINGDIR=/home/user/code/gaim-mtn
  $ mtn -d $DATABASE db init
  $ mtn -d $DATABASE pull pidgin.im im.pidgin.gaim
  $ mtn -d $DATABASE co -b im.pidgin.gaim $WORKINGDIR

(The variables here are just to help you understand which parts of the process are up to your personal choice.)

This will create a database for storing your Gaim development stuffs, fetch the entire revision history available from pidgin.im to that database, and then check out a working copy of the newest revision of Gaim in that database. To update the database from the server in the future, you can either a) simply go to $WORKINGDIR and execute mtn pull, or execute mtn -d $DATABASE pull from anywhere. Note that this will pull the new revision history from the server, but will not update your working directory to reflect the newest avaialble revision. For this, you need to run mtn up in $WORKINGDIR.

Consult the monotone documents, and particularly ​their CVS phrasebook to see the things you can now do with your database and working copy. You should find that most of the actions at this point feel pretty familiar.

At some point you will probably try to execute a command which requires a keypair. To generate a keypair, use mtn genkey $KEYID. Key IDs are normally email addresses, and at this point there is no way to use two keys with the same key ID on the same project (keys are addressed by their ID, not fingerprint etc.) For playing, you might want to generate a throwaway key ID just in case; I recommend that if we adopt monotone, all developers use a key of the form username@pidgin.im for normal development. There is nothing which says this must be the case, however, and there is certainly something to be said for using a different key for each physical workstation or administrative domain that one uses.

Important Practices

I recommend reading ​DaggyFixes in particular. The other material at ​BestPractices may be useful as well.

Comments

Please leave any comments you have about monotone usage that you think should be documented for our use, or should become part of our own best practices, here.

[lschiere]: I like the idea of fixing a bug at the original introduction point and then merging. That is likely more work than is worth-while for some bugs, but other bugs we have identified the bad revision as part of figuring out what is causing the bug. Along the same lines, the pluck command would be useful for backporting fixes when we are unable to fix the bug in the "daggy" manner.