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 "David Nuescheler" <[EMAIL PROTECTED]> wrote on 03/03/2006 04:43:22 AM: > > 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 versionhistory. > > > In subversion the version history of the new node (after a copy or move) > > 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 version > > history, it's shared by both nodes, up to the time of the copy, and the > > 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.
