I think there are use cases to keep history *and* to "forget" history.
What would be nice is to let do both. Even though it can be done by ourself, there is a performance issue with that. That said, if i am the only one who needs that, it does not worth the pain. On Friday 03 March 2006 11.14, Carlos Villegas wrote: > 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 <[EMAIL PROTECTED]> 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
