[
https://issues.apache.org/jira/browse/JCR-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-1463:
-------------------------------
Component/s: (was: jackrabbit-core)
jackrabbit-jcr-tests
Fix Version/s: (was: core 1.4.3)
Summary: TCK: testRestore assumes too much about OPV=VERSION (was:
Core: Failing version tests (testRestore....))
Agreed with Toby, reverted the 1.4 merge in revision 650308.
I dug a bit deeper on this. It seems that the root of the problem is that the
test case assumes that restore() will restore an OPV=VERSION child node to the
specific version it was in when the parent node was checked in. This is not
(always) true in Jackrabbit and not required by the JSR 170 spec.
The spec merely says the following about such a child node (c):
If the workspace does not have an instance of C then one is
restored from C's version history. The workspace in which the
restore is being performed will determine which particular version
of C will be restored. This determination depends on the
configuration of the workspace and is outside the scope of this
specification.
Jackrabbit by default uses the DateVersionSelector class that often makes it
look like the exact child version information is kept around in the frozen
node, but that is not the case as evidenced by the reported same-millisecond
versions causing the DateVersionSelector to select an "unexpected" child node
version. Note that this behaviour is perfectly acceptable, and there is no
reason why child node could not for example always be restored to the latest
available version, regardless of the version of the parent node.
Also, if the versioned child node already exists in the workspace, restoring
the parent node to some version should not (or at least may not) affect the
version of the child node.
Re-categorizing this as a TCK issue. We might also want to revert the changes
to jackrabbit-core in trunk.
> TCK: testRestore assumes too much about OPV=VERSION
> ---------------------------------------------------
>
> Key: JCR-1463
> URL: https://issues.apache.org/jira/browse/JCR-1463
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-jcr-tests
> Reporter: angela
> Assignee: Tobias Bocanegra
> Attachments:
> TEST-org.apache.jackrabbit.core.integration.JCRAPITest.xml
>
>
> i run into failing restore test in the core project while trying to reproduce
> JCR-1293.
> since that i had similar (or the same) tests failing more than once.
> therefore i guess this is really caused by a bug in the restore code or in
> the corresponding tests and not an maven-artifact.
> the next time i get it, i will attach the surefire report.
> regards
> angela
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.