I have been using github issues and I have to admit that being able to edit
messages after you have pressed the submit button is nice.

Message contents in Roundup are normally stored in the filesystem under
db/files/msg/X/msgY where Y is the message number (e.g. 4 for msg4) and
X = Y//1000 (where // is floor/integer division).

My thought on implementing editing for an unedited file msg3 is to move
msg3 -> msg3.1 and store the edited result in msg3. This allows quick access
to the newest file which I expect is what most people will request
while preserving previous versions.

Editing msg3 when msg.1 exists will move msg3 -> msg3.2 and a new msg3 file
will be created with the new contents. (This has shades of RCS, but for
low edit quantities it should be reasonably performant.)

The timestamp recorded in the database and on the files will be the edited
time. Timestamps for prior revisions will have to be taken from the history
records that record the old timestamp or from the revision files if you trust
that they are not changed outside of Roundup.

Adding an "edit_revision" counter to the msg class can make finding the last
revision easier than scanning the filesystem looking for the maximum msg3.n file.
Storing this metadata also works well if an alternate storage backend (database
BLOB/CLOB, AWS S3 ...) is used where scanning is more expensive.

Sending a notification email of the edit will probably require a reactor on the
msg class. I don't think there is a good way to trigger email via an auditor on
the issue. Having an "edit_revision" property that is changes makes detecting a
new revision reliable.

An alternate way of storing messaged edits is to replace msg3 with msg10 and abandon
msg3. This means relying on the issue's history to record the change from msg3 -> msg10
in the msgs multilink.

This raises a few issues:

  1) identifying the history of the message is more difficult as you have to generate
     a difference between the msgs value before and after and use the existence of an
     addition and a removal from the list to recognize an edit to the message.
     I am not sure that a simple add/remove would always indicate a message edit.
     I think the REST and XMLRPC can do arbitrary changes to msgs. So editing an
     issue's msgs to remove spam and add a message saying the spam was removed in
     a single transaction would incorrectly look like a msg edit. Also IIRC in the
     HTML interface this edit to the msgs MultiLink would have to be done in two
     passes/transactions.    

     Having to guess about msg replacement will make displaying message versions in the
     UI more difficult.

  2) The ordering of messages appears to be by id number. So when displaying the
     message thread, msg10 would be newer than the other messages and would be placed
     after msg 5 and 6 and 7 which would be confusing if msg 5 responded to msg3 which
     is now msg10 that occurs after msg5. Even writing this out is confusing.

  3) This does allow reuse of the nosy detector, but additional logic would be needed
     to report the change as an edit with the caveats as listed in 1.