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.
If your primary goal is to pull the latest development code, there is little to no setup required:
mtn db init --db=./syndie.mtnmtn genkey arbitrary@namemtn --db=./syndie.mtn pull mtn.i2p.net "syndie"mtn --db=./syndie.mtn checkout --branch=syndie./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
If you have any changes you want to make to the main Syndie branch, you can bundle
them up with mtn diff - mail that to a Syndie developer or the
syndie-commit mailing list at i2p.net. The changes will be reviewed and
applied and then pushed onto the mtn.i2p.net repository for everyone to
access. Over time, if you want commit priviledges on the mtn.i2p.net
repository, that can be arranged - see below for more details.
If you will be contributing to the codebase repeatedly, it may become simpler
to just get commit priviledges on the mtn.i2p.net repository directly.
If you feel you need this:
mtn genkey jrandom@i2p.netmtn genkey jrandom-transport@i2p.netcat >> ~/.monotone/monotonerc function get_branch_key (branchname) return "jrandom@i2p.net" end ^D
cat >> ~/.monotone/monotonerc
function get_passphrase (keypair_id)
if ("jrandom@i2p.net" == keypair_id) then
return "the_author_passphrase"
elseif ("jrandom-transport@i2p.net" == keypair_id) then
return "the_transport_passphrase"
else
return false
end
end
^Dmtn pubkey jrandom@i2p.net > keys.txt ; mtn pubkey jrandom-transport@i2p.net >> keys.txtOnce the keys are authorized, the long lasting nym will be added to the
mtn-committers file, and the transient nym will be granted write
permission to the mtn.i2p.net repository.
Monotone development cheatsheet:
mtn sync mtn.i2p.net --branch=syndiemtn commitCHANGES 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 statusmtn diffmtn add $filenamemtn drop $filenamemtn revert $pathmtn updatemtn log $filenamemtn headsmtn tag $revision $tagnamemtn 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 $tagnamecvs tag -F)