Skip navigation
Syndie - distributed forums

# Monotone howto

Monotone is a distributed version control system with tightly integrated cryptographic integrity and authenticity checks. This howto is not meant to be an exhaustive set of documentation on monotone (see their huge set of manuals and wiki for that), but merely a means to bootstrap Syndie developers.

## Tracking Syndie development

If your primary goal is to pull the latest development code, there is little to no setup required:

1. Install monotone
2. Create a monotone database:
   `mtn db init --db=./syndie.mtn`
3. Create a monotone nym:
   `mtn genkey arbitrary@name`
4. Pull the latest code into your monotone database:
   `mtn --db=./syndie.mtn pull mtn.i2p2.de "i2p.syndie"`
5. Check out the latest code from your monotone database into a new "workspace"
   `mtn --db=./syndie.mtn checkout --branch="i2p.syndie" syndie`
6. You're good to go! The code is now in `./syndie/`

Whenever you want to pull any more changes, run step 4 again, and then go into your monotone workspace (`./syndie/`) and run `mtn update`

## Contributing to Syndie development

If you will be contributing to the codebase repeatedly you'll want to get commit priviledges on the `mtn.i2p2.de` repository directly.

1. Create a long lasting monotone nym for development, using a valid email address:
   `mtn genkey yournick@mail.i2p`
2. Create a transient monotone nym for synchronizing with the repository:
   `mtn genkey yournick-transport@mail.i2p`
3. Make sure your commits will be signed by the long lasting nym:

       cat >> ~/.monotone/monotonerc
       function get_branch_key (branchname)
         return "yournick@mail.i2p"
       end
       ^D

4. You can have monotone remember the passphrases to those passwords as well:

       cat >> ~/.monotone/monotonerc
       function get_passphrase (keypair_id)
         if ("yournick@mail.i2p" == keypair_id) then
           return "the_author_passphrase"
         elseif ("yournick-transport@mail.i2p" == keypair_id) then
           return "the_transport_passphrase"
         else
           return false
         end
       end
       ^D

5. Send both public keys to zzz@mail.i2p so that they can be authorized
   `mtn pubkey yournick@mail.i2p > keys.txt ; mtn pubkey yournick-transport@mail.i2p >>keys.txt`

Once the keys are authorized the transient nym will be granted write permission to the `mtn.i2p2.de` repository.

Monotone development cheatsheet:

- `mtn sync mtn.i2p2.de --branch="i2p.syndie"`
  this pulls the latest changes from the repository into your database, and pushes your latest already-committed changes from your database into the repository.
- `mtn commit`
  this commits the local changes in your monotone workspace into your local database, signing the new revision with your nym key. Please be sure to update the `CHANGES` file with a bullet point for each substantial change above the most recent release. On the other hand, if you are making a new release, include a date and version line in `CHANGES`, update `VERSION`, as well as the version numbers in `doc/web/download.html`.
- `mtn status`
  this summarizes what files have changed in the monotone workspace
- `mtn diff`
  this details what has changed in the monotone workspace
- `mtn add $filename`
  this schedules a file for inclusion in the database on next commit
- `mtn drop $filename`
  this schedules a file for removal from the database on next commit
- `mtn revert $path`
  this undoes any local changes for the given path (which can be a file or directory)
- `mtn update`
  this pulls the latest changes from the local database into your workspace
- `mtn log $filename`
  this views the change history of the given file
- `mtn heads`
  this lists the revision ids of the unmerged paths on the current branch ("syndie")
- `mtn tag $revision $tagname`
  this cryptographically tags the given revision id with the specified tag (e.g. "`mtn tag a8af872 syndie-0.912b`"). note that the revision can be a short substring of the full revision id - "a8af872" instead of "a8af872ccdc00b5995dd1c05f15d8912804bba99"
- `mtn db kill_tag_locally $tagname`
  if the tag has not been pushed out onto any other databases, this will remove the cryptographic certificate that associates the given tag with a revision. This effectively allows you to move a tag (circa `cvs tag -F`)