jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Villegas <...@uniscope.jp>
Subject Re: Fwd: Copy versioned nodes
Date Fri, 03 Mar 2006 10:14:43 GMT
As I understand, in subversion, a repository copy, maintains the version 
history. However, if you don't want that, you can just do a filesystem 
copy and add the file to version control in the new place. Note that if 
a repository copy didn't maintain the version history, there's no way to 
do it after a file has been added to version control.

Carlos

Martin Perez wrote:
> IMHO, copying version history could leave to some problems.
> 
> One simple example. Imagine that you have a document in which you have
> worked internally for several days. That document will have many versions
> with all the changes you did. Now, you have the final version for that
> document and you copy the document to your manager's workspace. Imagine what
> would happen if your manager could see all the nasty comments about him that
> you put on the pre-final versions :-)
> 
> Well, this is only a silly example trying to explain that I think that the
> common case when copying a node is to get a clean copy, and not a copy with
> all the version history. Anyways, this does not mean that the other case is
> not possible or useful, but I think that it is not the ordinary case.
> 
> In my special case, i.e. jLibrary, users can export repositories and
> documents to share them with others. But, why those other users could be
> able to read the version history? Even more, I think that my users would not
> like that other users could be able to see all the things that they changed
> on the document.
> 
> Martin
> 
> On 3/3/06, David Nuescheler <david.nuescheler@gmail.com> wrote:
> 
>>hi carlos,
>>
>>thanks for the insight.
>>
>>
>>>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.
>>
>>regards,
>>david
>>
> 
> 


Mime
View raw message