Daniel Schoepe <daniel at schoepe.org> writes: > Sorry to keep harping on this, but I'm not entirely happy with the way > we handle notmuch-compact here (and in the other commit that mentions > compacting explicitly). Given that lastmod values (and pretty much > everything else) aren't affected by compacting, would it perhaps make > sense to copy the previous UUID to the newly compacted database?
We aren't currently maintaining a UUID for notmuch, but using Xapian::database::get_uuid(). There is no way in Xapian to change the UUID; even if there was, lying to Xapian probably would not be a good idea. We could maintain our own UUID, but I'm not sure it's worth the extra code just to make compaction slightly nicer. For me compaction is a rare event, so having to take the fallback path and do a full dump or whatever doesn't seem so bad. If you don't want to have a fallback path, then I guess you need to guarantee externally that no "bad changes" happen and either ignore the uuid's or copy them forward in your external tool. Mainly though I think this will be fixed in Xapian. As it happens Xapian developer Olly Betts is here at DebConf, and I discussed this problem with him. According to Olly, in-progress / future versions of compact will function in place, and guarantee the UUID is preserved. I'm not sure of the timeline here, but given our scarce developer resources, I think I'd rather wait for Olly to fix this. On the bright side, if in the future we decide that notmuch should have it's own notion of UUID, then this would would not change the library API or command line interface. There is some argument here for giving our name to the UUID, but "revision" turned out to be a terribly confusing choice in previous rounds of patches. The current transparent naming has the advantage of matching the output. d