[
https://issues.apache.org/jira/browse/JCRVLT-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552220#comment-17552220
]
Konrad Windszus commented on JCRVLT-598:
----------------------------------------
With a slightly different test package I can reproduce the issue:
[^test-duplicate-referencable-on-child-element-only.zip]
* Both nodes kept (one with newly assigned id) pre 3.5.2
* One node removed since 3.5.2
This is an inconsistency in FileVault pre 3.5.2 which has different behaviour
of conflict resolving depending on whether it affects the root DocViewNode or
some child.
> need IdConflictPolicy compatible with 3.5.0 behavior
> ----------------------------------------------------
>
> Key: JCRVLT-598
> URL: https://issues.apache.org/jira/browse/JCRVLT-598
> Project: Jackrabbit FileVault
> Issue Type: Sub-task
> Components: vlt
> Affects Versions: 3.5.8
> Reporter: Julian Reschke
> Assignee: Konrad Windszus
> Priority: Major
> Attachments: test-duplicate-referencable-on-child-element-only.zip,
> test-referenceable.zip
>
>
> Currently, according to the documentation
> (https://jackrabbit.apache.org/filevault/referenceablenodes.html),
> "IdConflictPolicy.FORCE_REMOVE_CONFLICTING_ID" is supposed to behave as 3.5.0
> did.
> My tests show however that in 3.5.0, when importing a package with two nodes
> with conflicting UUIDs, both nodes were imported (and one of the UUIDs
> changed).
> From that point of view, CREATE_NEW_ID seems to be closer (but that one
> assigns new UUIDs to *both* nodes).
> Proposal: adjust CREATE_NEW_ID behavior to keep assigning a new UUID only
> when needed (thus preserving it for one of the nodes), and document *that*
> mode as compatible to 3.5.0.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
