From: Tom Prince <tom.prince@ualberta.net>
To: Austin Clements <amdragon@MIT.EDU>, David Edmondson <dme@dme.org>
Subject: Re: [PATCH 0/5] Store message modification times in the DB
In-Reply-To: <20111219194821.GA10376@mit.edu>
References: <1323796305-28789-1-git-send-email-schnouki@schnouki.net>
	<cunk45szfiu.fsf@hotblack-desiato.hh.sledj.net>
	<20111219194821.GA10376@mit.edu>
User-Agent: Notmuch/0.5-118-gdcdb843 (http://notmuchmail.org) Emacs/23.3.1
	(i686-pc-linux-gnu)
Date: Mon, 19 Dec 2011 15:56:39 -0700
Message-ID: <87r500cgrc.fsf@loki.hocat.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: notmuch@notmuchmail.org
Precedence: list

On Mon, 19 Dec 2011 14:48:21 -0500, Austin Clements <amdragon@MIT.EDU> wrote:
> This protocol requires significantly more state, but can also
> reconstruct per-tag changes.  Conflict resolution is equivalent to
> what git would do and is based solely on the current local and remote
> state and the common ancestor state.

This seems like exactly what one would get if one stored the tag state
in git, which seems like a reasonable thing to do anyway. 

> This can lead to unintuitive results if a tag on a message has gone
> through multiple changes on both hosts since the last sync (though, I
> argue, there are no intuitive results in such situations).

I certainly agree that there isn't a universally good resolution to
this. I suspect that the same person, making the same tag changes with
the same mtimes, will want different resolutions at different
times. This is because there is no good way to record the intent of the
changes.

> Tombstones are only required to garbage collect sync state (and other
> techniques could be used for that).

I wonder how many people using notmuch actually delete mail? I know I
don't bother to, anymore.

One use case that was mentioned, is having a limited amount of mail on a
portable device, and syncing tags on those message present. Using git to
record the tag state, one would just need to record the state before
deleting files, to avoid the need for tombstones in the notmuch db.

  Tom