Infrastructure

I just read the documentation of the system metadata and found both "obsoletedBy" and "obsoletes" are mutable. So we should allow the change happen. But we can't allow to create a branch like the scenario which Andrei described. So we have two options:
1. Totally trust user - we assume the user will call another mn.updateSystemMetadata(p2); it will set p2 obsoletes null. Then the new branch will disappear.

1. When mn.updateSystemMetadata change the field of obsoletedBy, it also will change the system metadata of pid in the obsoletedBy field (this case is p2). The "obsoletes" of p2 will be set to null. If p2 doesn't exist in the node, the update still succeed. If the update on p2 system metadata fails, the method call fails as well. Same scenario apply to "obsoletes" too.

Option (1) with completely trusting the user makes me nervous. I was thinking we could block the change and pass back a message along the lines of "To set the obsoletedBy value, you need to first clear the obsoletes value of this other pid, to avoid inconsistencies".
Option (2) sounds better to me. It's more complicated logic, but also more user-proof.

The "obsoletedBy" and "obsoletes" only can be set once. So the above resetting will fail.

Hi Peter:

Your request is different to this ticket. The purpose of this ticket is prevent from generating a branch:
p1: p1 obsoletedBy p2
p2: p2 obsoletes p1.

But when you update system metadata of p3, you can't set p3 obsoletes p1 since this will generate branch.

In our original design, we don't have the feature you requested (automatically update the system metadata of p1 by setting obsoletedBy), you have to call the updateSystemMetadata on p1 as well in order to set the obsoletedBy field.