[ 
https://issues.apache.org/jira/browse/JCR-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559532#action_12559532
 ] 

Tobias Bocanegra commented on JCR-1314:
---------------------------------------

i think the spec is wrong:

in 8.2.10 it says:

If N is currently checked-in then: 
  1) If V' is a successor (to any degree) of V, then the merge result for N is 
update. 
  2) If V' is a predecessor (to any degree) of V or if V and V' are identical 
(i.e., are actually the same version), 
       then the merge result for N is leave. 
  3) If V is neither a successor of, predecessor of, nor identical with V', 
then the merge result for N is failed. 

If N is currently checked-out then: 
  4) If V' is a predecessor (to any degree) of V or if V and V' are identical 
(i.e., are actually the same version), 
       then the merge result for N is leave. 

1) means, if the version you merge against is newer, do an update
2,4) mean, if the version you merge against is older or same, leave it

where as in 8.2.10.1:
 a) if v' is a successor of v and n is not checked-in doupdate(n, n'). 
 b) else if v is equal to or a predecessor of v' doleave(n). 

a) means, if the version you merge against is newer and checked-out, do update. 
which is the same as 1)
b) means, if the version you merge against is newer or same, do leave. which is 
not the same as 2,4)

so i think the code is correct. which also makes sense, since you don't want to 
update to an older version.

are you sure you did the merge the right way around ? can you provide a test 
class ?

> Node incorrectly overridden when performing a merge
> ---------------------------------------------------
>
>                 Key: JCR-1314
>                 URL: https://issues.apache.org/jira/browse/JCR-1314
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: versioning
>    Affects Versions: 1.4, 1.5
>            Reporter: Bob Wieler
>            Priority: Critical
>
> The implementation of the merge algorithm provided in the JCR specification 
> is incorrect and can result in nodes being overridden. This can be 
> demonstrated by the following simple steps:
> 1. Create a repository with a nt:file node containing whatever data (n')
> 2. Commit the changes to the node to create the initial version (v')
> 3. Copy the node to a new workspace
> 4. Edit the node in the second workspace (n)
> 5. Commit the changes to the second workspace to create the second version (v)
> 6. Merge the changes from the first workspace into the second workspace
> According to the JCR specification (from 8.2.10.1):
> if v' is a successor of v and n is not checked-in doupdate(n, n'). 
> else if v is equal to or a predecessor of v' doleave(n). 
> else dofail(n, v').
> In the above example, v' is a predecessor of v so the doupdate(n, n') is not 
> done. v and v' are also not equal and v is not a predecessor of v' so the 
> doleaven(n) is not done. Therefore the dofail(n, v') is what should be called.
> The code in NodeImpl.java is not however doing what is expected. Line 3337 in 
> NodeImpl.java (subversion revision 611855) has the following:
>         } else if (v.isSame(vp) || v.isMoreRecent(vp)) {
>             // If V' is a predecessor (to any degree) of V or if V and V' are
>             // identical (i.e., are actually the same version), then the merge
>             // result for N is leave. This case can be thought of as the case 
> where
>             // N' is "older" or the "same age" as N and therefore N should be 
> left alone.
>             return null;
>         } else {
> The doMergeTest method returns null (essentially a doleave(n) in the spec 
> algorithm) if v and v' are the same or v' is a predecessor to v - in other 
> words if v and v' are the same or v is a _successor_ to v' - which is exactly 
> the opposite to what the specification  requires (if v is equal to or a 
> _predecessor_ of v'). The proper if statement would be to have:
> } else if (v.isSame(vp) || vp.isMoreRecent(v)) {
> Unfortunately, this was causing us to lose data when performing a merge. I 
> have updated our version of jackrabbit with the above change and merging now 
> works as expected.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to