Limitations of Monotone

This page lists limitations of monotone which will affect Pidgin developers, as well as known workarounds and upstream status. It is not intended to be a monotone bug tracker, but rather a place to gather high-priority problems which we might want to either work on in monotone or bring to the attention of the regular monotone developers.

• Key ID/key name conflation - Developers lose their private keys with frightening regularity. This is a real problem for monotone, as new keys cannot have the same key ID as the key they replace. Since we use email addresses which we intend to be valid, this rapidly burns up namespace.
  • Monotone 0.45 has a new keys-by-hash feature with which we can have multiple keys with the same ID. Moving to this, however, requires a "flag day" where all developers/contributors are required to use mtn 0.45 or newer as soon as we have signatures from two different keys having the same ID.
• die-die-die - mtn merge_into_dir is nearly useless for us, because of die-die-die merge semantics. For example, this is why libgnt cannot conveniently be maintained out-of-tree with an in-tree merge_into_dir copy.
• No workspace merge - The inability to perform logical fixups at merge-time (only conflict fixups) introduces a glitch into our traditional "Pidgin should always compile" philosophy. While we recognize that a DVCS may require some workflow changes, this isn't one we're ready to give up on, yet. This is being worked on upstream but doesn't seem to be quite ready yet.
• Partial Pull - Complete (initial) pulls of Pidgin are over 45 minutes on a fast connection. This is too long to expect any casual developer to invest. There are several possible mitigations for this (and monotone is working on both complete pull improvements, and partial pull):
  • We currently provide a monotone database for download; this bootstraps the process, and is faster and smaller than an initial netsync transfer. At the time of this writing, however, the bzip2'd database is nearly 230MB. This is still not ideal.
    • We may want to investigate whether other compression options might be useful. For example, lzma can yield significant compression improvements over bzip2 for many types of data, particularly when cranking the compression to maximum at the expense of CPU time.
  • Provide a monotone-to-svn (or similar) gateway for "casual" development. Obviously the severe limitations of svn will make this painful for serious development, and we would not provide a svn-to-monotone gateway; however, for one-off patches from parties with limited interest, it would probably suffice.
  • Provide a periodically generated tarball containing a snapshot of the head of im.pidgin.pidgin and possibly im.pidgin.pidgin.next.minor for download.
    • This would probably encourage even more users to run development code than an svn gateway would.
    • If we do this we might want to consider doing only weekly snapshots.
• No way to "preview" a netsync - Almost every developer has, by now, asked for a mtn push --dry-run type command.