| 1 | = Using Montone for Pidgin = |
| 2 | |
| 3 | [http://venge.net/monotone 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. |
| 4 | |
| 5 | == External Documentation == |
| 6 | |
| 7 | * The [http://venge.net/monotone/docs/index.html official manual] |
| 8 | * The [http://venge.net/monotone/wiki/ monotone wiki] has a lot of good information, as well |
| 9 | |
| 10 | == Getting Started with Pidgin monotone == |
| 11 | |
| 12 | There is currently an experimental monotone server running on pidgin.im, which fetches nightly changes from Gaim SVN (by way of [http://www.darcs.net/DarcsWiki/Tailor 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. |
| 13 | |
| 14 | To fetch the revision history from this server, and check out a working copy, do: |
| 15 | |
| 16 | {{{ |
| 17 | $ DATABASE=/home/user/monotone_databases/gaim.mtn |
| 18 | $ WORKINGDIR=/home/user/code/gaim-mtn |
| 19 | $ mtn -d $DATABASE db init |
| 20 | $ mtn -d $DATABASE pull pidgin.im im.pidgin.gaim |
| 21 | $ mtn -d $DATABASE co -b im.pidgin.gaim $WORKINGDIR |
| 22 | }}} |
| 23 | |
| 24 | (The variables here are just to help you understand which parts of the process are up to your personal choice.) |
| 25 | |
| 26 | 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}}}. |
| 27 | |
| 28 | Consult the monotone documents, and particularly [http://venge.net/monotone/docs/CVS-Phrasebook.html#CVS-Phrasebook 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. |
| 29 | |
| 30 | 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. |
| 31 | |
| 32 | == Important Practices == |
| 33 | |
| 34 | I recommend reading [http://venge.net/monotone/wiki/DaggyFixes DaggyFixes] in particular. The other material at [http://venge.net/monotone/wiki/BestPractices BestPractices] may be useful as well. |
| 35 | |
| 36 | == Comments == |
| 37 | |
| 38 | 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. |