jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Nuescheler" <david.nuesche...@gmail.com>
Subject Fwd: Fwd: Copy versioned nodes
Date Fri, 03 Mar 2006 13:17:47 GMT
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

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.


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.

View raw message