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:[EMAIL PROTECTED] Sent: 03 March 2006 13:18 To: [email protected] 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 <[EMAIL PROTECTED]> Date: Mar 3, 2006 1:38 PM Subject: Re: Fwd: Copy versioned nodes To: [EMAIL PROTECTED] Cc: [email protected] 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.
