jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Miro Walker" <miro.wal...@cognifide.com>
Subject RE: Fwd: Copy versioned nodes
Date Fri, 03 Mar 2006 13:39:04 GMT
Hi Geoff,

Sorry if I'm just being ignorant here, but what exactly is a



-----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
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
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

So although JCR does not currently support change-sets, it is
ready", by maintaining the invariant needed to support change-sets.
If the expert group is interested, we can add change-sets to JSR-283.


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
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.

View raw message