Re: Tree-conflicts: HEADS UP: update failure with tc-siblings :0

Stephen Butler wrote:
> Instead of keeping conflict structs in memory until the parent dir is
> closed, why don't we write each tree conflict immediately? That would
> eliminate the possibility of lost conflicts on cancel.

And it would make the fix a lot simpler. If the code turns out to be too
slow, we can still add the bunching together later on. Going the simpler way
is better at this time.

I wonder though if there could be any problem with the tree-conflicts being
recorded immediately and all the other node changes stored in the log being
made only later on.

I think the "best" fix of this would be to have a new log command, as in
<entry-add-tree-conflict data="B:dir:..."/>. Are there any interface reasons
preventing that?

We could also set the tree-conflict data on the *victim* when writing to the
log, and append victims' tree-conflict data to their respective parents
during log replay...

I have implemented the simple fix (write tree-conflicts immediately) quicker
than writing this mail and it seems to cause no new test failures. So I'm
committing that, while above alternatives remain open.

Thanks!
~Neels