jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Kuchlein <kuchl...@gmail.com>
Subject Re: Merging non-versionable nodes
Date Mon, 16 Jul 2007 20:17:26 GMT
Hello

I am currently having the same issue with merging two workspaces and  
I noticed that no one has responded to this issue.  I can't see how  
the algorithm presented in JSR-170 (8.2.10.1) or the newly released  
JSR-283 could possibly implement the textual description (8.2.10).   
Nowhere in the algorithm is the merge result of the nearest  
versionable ancestor taken into consideration.  Specifically the  
version of doleave(n) that dofail(n, v') calls needs to be altered to  
read:

	doLeave(n)
	  for each versionable child node c of n domerge(c).

rather than what is currently has:

	doLeave(n)
	  for each child node c of n domerge(c).

thanks in advance
tim

On Jul 5, 2007, at 11:24 AM, Bob Wieler wrote:

> From: Bob Wieler <bob.wieler@gmail.com>
> Date: Jul 5, 2007 11:24 AM
> Subject: Merging non-versionable nodes
> To: users@jackrabbit.apache.org
>
> Hi,
>
> I am hoping that someone can help me with what seems to be a  
> problem with the merging of non-versioned nodes (I am currently  
> using Jackrabbit 1.3). I am using a workspace that contains  
> versionable nodes with a number of non-versionable referenceable  
> children. After performing a merge the non-versionable children are  
> merged even if a conflict exists in the parent versionable node.
>
> Unless I am greatly misunderstanding the JCR specification (both  
> the current JSR-170 and upcoming JSR-283) there appears to be a  
> conflict in the section describing merges and the algorithm  
> provided (which Jackrabbit implements).
>
> From JSR-170 section 8.2.10 Merge:
>
> "In either case, (regardless of whether bestEffort is true or  
> false) for each non-versionable node (including both referenceable  
> and non-referenceable), if the merge result of its nearest  
> versionable ancestor is update, or if it has no versionable  
> ancestor, then it is updated to reflect the state of its  
> corresponding node. Otherwise, it is left unchanged."
>
> From this I read that if a versionable node has a merge result  
> other than update (a failure) then any non-versionable children of  
> that versionable node should be left unchanged (assuming bestEffort  
> is true of course). However the algorithm presented in 8.2.10.1 of  
> the specification seems to go against the above statement.
>
> On a dofail(n, v') if bestEffort is true then the jcr:mergeFailed  
> property is set, the UUID is added to the failedset, and then  
> doleave(n) is done. doleave states that for each child node c of n  
> domerge(c) which in turn will perform a doupdate(n, n') for non- 
> versionable children.
>
> Am I missing something fundamental about the way merging of nodes  
> should be done in JCR? If the merge of a versioned node fails  
> shouldn't it just perform a merge of the versioned child nodes  
> rather than all of the child nodes?
>
> Thank you for your help,
>
> Bob Wieler
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message