jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey M Clemm <geoffrey.cl...@us.ibm.com>
Subject Re: Fwd: Copy versioned nodes
Date Fri, 03 Mar 2006 12:59:52 GMT
One additional note:

It would be fine to record the "lineage" of the new version-history
created by the copy, by adding a property to the version-history that 
is a reference to the version from which that new version-history was 
We could call it the "copy-source" property.  This copy-source property 
give folks all the information they need, without violating the change-set 

invariant.  Someone that wants to reconstruct the "cross-copy history", 
do so by traversing both predecessor references and copy-source 
references.  If 
we want to doubly link the data structure, we could add a 
reference, that is the inverse of the copy-source reference.


"David Nuescheler" <david.nuescheler@gmail.com> wrote on 03/03/2006 
04:43:22 AM:

> hi carlos,
> thanks for the insight.
> > When you copy a versionable node in jackrabbit, is its version history
> > reset? I mean the new node starts with a fresh version history?
> correct. not just in jackrabbit but in jcr in general.
> the node will get a new uuid and therefore will get a new 
> > In subversion the version history of the new node (after a copy or 
> > starts with the version of the source node at the time of the copy.
> move of course works the same way in jcr. copy doesn't.
> > Thus
> > when you examined the version history of the copied node, you see the
> > versions in the new place plus the versions when it was in the old
> > place. I believe that's why it's not necessary to copy the whole 
> > history, it's shared by both nodes, up to the time of the copy, and 
> > fact that it was copied it's also recorded.
> hmm... i am not sure i can see all the consequences of sharing
> a version history between two nodes within the same workspace.
> for example cloned nodes in different workspaces of course share
> one version history.
> while i am still looking for a good reason why version histories in
> general are not copied (at least in my experience) in any config
> management environment, i believe that copying a version history
> (with all its original timestamps) would be sort of "lying" about what
> happend to a node in the past.
> regards,
> david

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