Resolving conflicts on wide revision trees


#1

Is there a way to efficiently clean up a WIDE reivision tree where there are a lot of conflicting branches? /open_rev=all takes forever to return and when you delete all revisions except current, also takes forever. Just interested in cleaning up the revision tree and keep current ONLY. Is there a quick and dirty way to achieve this besides purge and recreate doc?

Working with SG 1.5.1


#2

If you just want a quick way to trim all the branches and let the default showing branch to win try this:

I made it so that someone in production who never thought they would have conflicts but they really do can have a quick solutions.


#3

I don’t think there’s any simple way to instantly nuke all but one branch. You must have a lot of branches if those API calls are taking a long time!

What I would do is:

  1. GET the current revision
  2. Purge the document
  3. PUT the current revision back to the document, using new_edits=false to preserve the _revID.

#4

Thanks @househippo thats a good idea to use changes feed for detection

@jens, that’s kind of what i figured, but thanks for the note about putting back the revision id using purge. That’ll make things a lot easier.

In certain circumstances clients were creating huge wide trees (thousands of branches) during replication probably because the revision tree depth was not high enough to support the offline scenario.


#5

@jens one complication is that this strategy doesn’t play well with the messed up clients? Won’t they just push the garbage revisions back to the server? All the purges would have to be coordinated with the clients as well right?

Maybe the strategy should be recreate the document with all the garbage revisions tombstoned? Not sure quite how the signature of the _revisions property on PUT /doc works. Can you just specify the tombstoned revisions in the “ids” array?

"_revisions": {
    "start": 0,
    "ids": [
      "string"
    ]
  },