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 12:38:55 GMT
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" <david.nuescheler@gmail.com> 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.

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