[Csync2] synchronizing file deletions

[Lars Ellenberg]

Problem with "auto resolve strategies" and removal is: how do you
determine if the removal is older/younger than the other modification?

You don't really have a time stamp to compare with...
Ok, you could use the time stamp of the entry in the dirty table,
which we don't have yet. That would be the timestamp from when
csync2 *noticed* that the file was deleted, which would probably be
the closest thing to a "deletion time" we will ever have.

On Wed, May 22, 2013 at 05:13:24PM -0400, Michael Johnson wrote:
> Looking at the code, I see that it would be a big change
> to implement cascading resolution strategies.
> 
> It looks like the only resolution strategy that works
> unconditionally is first.
> 
> I need to think about whether the first strategy will
> be acceptable in my use case.
> 
> I'll attach my current patch again, in case you want to
> see what I've been doing there. It passes all the other
> tests, and I understand why it fails 4 of my 60 hub-and-spoke
> tests.

Cool.
Sorry, no time to actually review that now, but will do as time permits.

Just this:
TAP allows for "TODO" tests,
test cases that "should" work eventually, but are known to not work yet.

You just add a
TEST_TODO(),
and make sure that it appends "# TODO " to the "ok/not ok" line.
not ok $testnumber # TODO arbitrary text here

It would not mark the whole test run as failed,
but would give "bonus points" once the test passes.

	Lars