Community
Participate
Working Groups
Build Identifier: 4.0 When trying to commit a change for a re-attached object on a branch you will get either an 'NPE' in case of a containment change, or an 'ISE: Origin revision not found' in case of an attribute change. The problem is that the ReattachTransition will use the version from the branch the object was branched from, instead of a new version. Reproducible: Always Steps to Reproduce: 1. Create an (containment) object, do some changes/commit to increase the version on the object. 2. Create a branch, detach the object (containment), reattach it and commit. 3. Do another change on the object (containment) to create a RevisionDelta with the faulty version, try to commit.
Created attachment 178417 [details] Testcase
Created attachment 178418 [details] Proposed patch Resetting version in case of branch change on re-attach.
1) The number of lines that you changed is smaller than 250. confirmed. 2) You are the only author of these changed lines. confirmed. 3) You apply the EPL to these changed lines. confirmed.
The patch avoids the exceptions, but I'm not sure it addresses the problem in the best possible way, because the fix performs work that should IMO be done by AbstractCDORevision#adjustForCommit. I'm still debugging to understand why this doesn't work.. perhaps Pascal has already investigated this? Flagging for Eike's review anyway, but I don't recommend committing this yet. (BTW, this problem is also partially due to the fact that our client-side logic doesn't net out redundant deltas -- but that's a more general issue that we can address separately.)
Created attachment 178485 [details] Patch v2 Here's my own stab at a patch. I believe the problem was not that the ReattachTransition DIDN'T change the branch, but rather that it DID. In other words, it was prematurely setting the branch of the reattached revision to the transaction's *current* branch. But this adjustment shouldn't be made until postCommit time, by AbstractCDORevision#adjustForCommit.
I completely agree that the version adjustments should be handled in adjustForCommit, so I took another look: The reason it wasn't caught by the code already present in adjustForCommit is that the branch in the revision for reattached objects will always be the current branch (Line 693: revision.setBranchPoint(transaction.getBranch().getHead());) no matter what branch the revKey acutally came from. ahh cheers, you beat me :)
Created attachment 178675 [details] Patch v3 - ready to be committed I included the tests in AllConfigs
Committed to HEAD
