SGW conflict resolution in light of sg auto-compaction

[traun]

I received this question over email:

Since compaction deletes revision bodies of all non-leaf bodies, am I correct in assuming that three-way merges are not possible (since common ancestor body would be removed)

The compaction process will only delete revision bodies of non-leaf revisions for docs that don’t have any conflicts. For docs with conflicts, it’s not safe to delete those revision bodies since they might need to be resurrected as the body of the winning branch based on the conflict resolution business logic.

[traun]

I missed the common ancestor aspect, so here’s a correction. If you have a rev tree like this:

and wanted to do a 3 way merge between:

2-966a1fab90a810dc0a63565b70680e4e
2-566a1fab90a810dc0a63565b70680e4e

and their common ancestor:

1-fc2cf22c5e5007bd966869ebfe9e276a

this would most likely fail since rev 1-fc2cf22c5e5007bd966869ebfe9e276a would be “auto-compacted” away. The exception is that if you were fast enough, and caught it within the 5 minute expiry window before 1-fc2cf was auto-compacted, it would actually work.

The reason 1-fc2cf is auto-compacted away is that before the conflicting branches are added, and the revtree looks like this:

Sync Gateway decides that there’s no good reason to keep around 1-fc2cf, since it already has the latest revision in the linear history, and so it backs up the rev body associated with 1-fc2cf and sets a 5 minute expiry on it. (I can’t recall exactly why it doesn’t just delete it immediately)

[pankaj.sharma]

write a blog on this @traun will help a lot of people finding this good material.