From: Michal Sojka <sojkam1@fel.cvut.cz>
To: Carl Worth <cworth@cworth.org>, notmuch@notmuchmail.org
Subject: Re: [PATCH v4 0/4] Maildir synchronization
In-Reply-To: <87oc9ykzae.fsf@yoom.home.cworth.org>
References: <87tyk3vpxd.fsf@wsheee.2x.cz>
	<1288560558-18915-1-git-send-email-sojkam1@fel.cvut.cz>
	<877hgsrjau.fsf@yoom.home.cworth.org> <87d3qhq527.fsf@resox.2x.cz>
	<874obrmww9.fsf@yoom.home.cworth.org>
	<87iq066cbd.fsf@steelpick.2x.cz>
	<87oc9ykzae.fsf@yoom.home.cworth.org>
User-Agent: Notmuch/0.4-30-ga01dbf0 (http://notmuchmail.org) Emacs/23.2.1
	(x86_64-pc-linux-gnu)
Date: Wed, 10 Nov 2010 00:39:31 +0100
Message-ID: <877hgm2hjg.fsf@steelpick.2x.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

On Tue, 09 Nov 2010, Carl Worth wrote:
> The updating I've done here only goes as far as just before "Add a
> message to new/ without info". And it looks like one change I made
> inadvertently broke a later test, so it's expected that "Check that
> removing info did not change tags" currently fails. [And this failure
> shows what I don't like about test_expect_success---if we were using
> test_expect_equal it would be trivial to see what problem I made
> here.]

Did you try ./maildyr-sync -v? In fact, this is what I don't like about
test_begin_subtest. test_begin_subtest does not hide debug output that
goes to stdout and should only be shown with -v. I admit that
test_expect_success is not ideal though. Without -v, it should
automatically show stdout when a test fails. I'll send patch for this in
another mail.

> 
> Finally, when going through these tests I saw:
> 
> 	"Removing of unread tag should fail without cur/"
> 
> And that's behavior I do not want. Adding and removing tags should be
> reliable whether or not the maildir synchronization can succeed. In this
> specific case, the right answer is probably to say that a directory
> without "new" and "cur" is not a maildir so no synchronization should be
> done.

This only fails if the message is in */new and there is no */cur.

> Notmuch does need to be able to support things like mh format still. Do
> the current patches break that by doing maildir-style renaming in
> non-maildir directories?

I do not know if MH format has something special or it is just plain
files in plain directories. If the latter, the synchronzation should
work unless one of the directories is named 'new'. See the tests with
fakenew directory [fakenew is probably not the most obvious name for a
simple non-maildir directory].

> If so, we'll need to fix that as well. And that might require an
> "is_maildir" term to be stored for directory documents in the
> database.
> 
> Again, that's something I can help with.

If you think that what we have now is not sufficient, I'd need some help
with this.

-Michal

P.S. Because of my work on test suite, I didn't do any additional tests
for maildir synchronization, so maybe tomorrow :-(