Just a response to some of Mark's points, re. the very rough prototype I mentioned in another email in this thread:
id:[email protected] All of my answers are based on my current implementation, and don't necessarily reflect the best possible way to address these problems. On Thu, 29 Apr 2010 14:01:59 -0600, Mark Anderson <[email protected]> wrote > Wouldn't it be good to have a timestamp associated with the application > of a tag, especially if you're going to manage a bug workflow with > tags? I sort of fake this by having timestamps come with pushing. Of course then it doesn't reflect the time of the tagging, but the time of the pushing. But if there were an internal db timestamp on the tag, that might be even better. > You'll be going cross geography, so UTC sounds nice. Yeah, I should change it to that. > But what happens if a bug goes from OPEN->CLOSED->REOPENED->CLOSED->..., > can you track that state with a simple tag cloud? Depends if you push in intermediate states. It will be recorded as prefaced with a + or - depending. See the link I give to a sample public log in the announcement email. The file that you push to/pull from will thus have a whole history for each tag in the namespace. Note that it will be "reduced" before being applied to your current db, when you pull. > How would you handle conflicts for the bug tracker? Suppose two people > close the bug in different ways, and one fix goes through several state > switches before being committed to a globally visible repository. The tag would only be in your inbox in its latest state. (See above about "reducing" before applying.) But you can see the history for any msg-id. > Does this really work with distributed development? No idea. Worth a try. Best, Jesse _______________________________________________ notmuch mailing list [email protected] http://notmuchmail.org/mailman/listinfo/notmuch
