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 13:53:44 GMT
A "change-set" is a "logical change" the the system (like a "patch") 
except that it can contain changes to multiple nodes (thus the term 
"change-set").  When a node has been previously renamed/moved in the 
either the source or destination workspace of a merge, when the change-set 
is applied to the destination, the system needs to know to which node a 
given change should be applied.  It would usually be wrong to apply a 
change to all of the nodes that have been copied to each other, and you 
don't want to ask the user which nodes it should be applied to, because 
they will usually not know (and if they were to guess, would get it 

Another way to think about it is that "the version history contains all 
versions from nodes with a given UUID".  When you copy() a node, you have 
to produce a node with a different UUID (since you cannot have two 
different nodes in a workspace with the same UUID), and so all versions 
from that copied node must go into a different version history.


"Miro Walker" <miro.walker@cognifide.com> wrote on 03/03/2006 08:39:04 AM:

> Hi Geoff,
> Sorry if I'm just being ignorant here, but what exactly is a
> "change-set"? 
> Thanks,
> Miro
> -----Original Message-----
> From: David Nuescheler [mailto:david.nuescheler@gmail.com] 
> Sent: 03 March 2006 13:18
> To: jackrabbit-dev@incubator.apache.org
> Cc: Geoffrey M Clemm
> Subject: Fwd: Fwd: Copy versioned nodes
> since geoff's email didn't make it to the list.
> please find his insights below.
> many thanks to geoff.
> ---------- Forwarded message ----------
> From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
> Date: Mar 3, 2006 1:38 PM
> Subject: Re: Fwd: Copy versioned nodes
> To: david.nuescheler@day.com
> Cc: jackrabbit-dev@incubator.apache.org
> The reason Subversion can get away with treating a copy() like a move()
> is that it doesn't really support change-sets.  When an SCM system
> support change-sets, it needs to maintain the invariant that there is
> only one location in the workspace that has file from a given
> version-history,
> so that when you merge a change-set into that workspace, the system
> knows into which file a given change should be merged.  Preserving the
> version-history for a move() is fine ... there is one location for a
> given
> history before the move(), and a single (different) location for that
> version-history after the move().  But preserving the version-history
> for a copy() would violate the one-location per version-history per
> workspace
> invariant.
> So although JCR does not currently support change-sets, it is
> "change-set
> ready", by maintaining the invariant needed to support change-sets.
> If the expert group is interested, we can add change-sets to JSR-283.
> Cheers,
> Geoff
> 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
> created.
> We could call it the "copy-source" property.  This copy-source property
> would
> give folks all the information they need, without violating the
> change-set
> invariant.  Someone that wants to reconstruct the "cross-copy history",
> could
> do so by traversing both predecessor references and copy-source
> references.  If
> we want to doubly link the data structure, we could add a
> "copy-destination"
> reference, that is the inverse of the copy-source reference.

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