Damien just schooled me on what should happen if a doc is deleted and then re-created, i.e. after
Currently in TouchDB the last revision that resurrects the document has no parent and a generation of 1, just like the first revision. This makes some sense, but leads to the rather nasty situation of #205. It also complicates the winning-revision algorithm. I think it could also lead to weird conflicts in some scenarios.
What should be happening — what CouchDB does — is that the resurrected revision should be a child of the tombstone. Its rev ID will start with "3-". This ensures it has a unique rev ID, avoiding #205, and also ties it into the same timeline that the deletion occurred on.
Real fix for 'resurrection' of deleted doc
A PUT, DELETE, PUT sequence should result in a rev with generation 3
that's a child of the tombstone revision.
This fixes #207 and is the real fix for #205.