You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Thomas Heute <th...@jboss.org> on 2006/03/02 16:42:44 UTC
Copy versioned nodes
Hello,
I am trying to copy versionable nodes using workspace.copy([...]) with the 0.9
version of JackRabbit
From what i experienced, only the latest revision seems to get copied.
This is unfortunately not defined by the spec.
What i would need is to copy all the versions or a version with a certain tag.
Could you please confirm that i need to do the copy by myself ? Or should we
change the way it is implemented in jackRabbit ? (Or did i miss something
since i am fairly new with JSR 170/JackRabbit.
Thanks in advance and thanks for the good work,
Thomas.
Re: Fwd: Copy versioned nodes
Posted by David Nuescheler <da...@gmail.com>.
hi thomas,
i think you may describe something in your use case that
may well be taken care of by two separate workspaces in jcr.
one would be the "live" workspace that displays a
specifically tagged version, while there may be a number of
"work-in-progress" or "user" workspaces.
you may want to use clone(), merge(), update() or
restore() to get a particular version into the "live"
workspace.
this also has the effect that the nodes in the different
workspaces share the same version history.
regards,
david
Re: Fwd: Copy versioned nodes
Posted by Thomas Heute <th...@jboss.org>.
On Friday 03 March 2006 09.14, David Nuescheler wrote:
> hi thomas,
>
> i think this is an interesting usecase that you mention.
>
> clearly jcr does not expect such an operation, and i have to admit
> in my experience (cms) it was never necessary to copy the version
> history. also, since geoff clemm as the main driver of the versioning
> portion of the jcr spec has never mentioned such a need, despite
> his extensive background in config management, i wonder if
> this has a deeper reason.
This is all about user experience, i am asking this for the JBoss Portal CMS
based on Jackrabbit and to be honnest with you i am not sure what the user
would want to do by copying.
As of today, all files are versioned but only one is publicly available (a
tagged version). It means that you can have your live revision that is not
the latest revision, when you copy that file, i think the end-user will
expect to copy the live revision.
It a more general manner, copying a tagged revision of a tree could be an
interesting feature to propose. I am new to CMS and probably have some weird
ideas in that field.
Thanks for your interest David.
Thomas.
Re: Fwd: Fwd: Copy versioned nodes
Posted by Carlos Villegas <ca...@uniscope.jp>.
David Nuescheler wrote:
> 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.
>
Well, I may be wrong, but this is what I thought subversion does, and
what I meant in previous post. It's not that the two nodes after the
copy share the same version history but that a node was a different node
in a previous version! The copy itself registers a new version in the
destination, and the precesessor of that version is the version of the
source node at that time, in other words with created a branch. In
subversion, a branch is implemented as a copy.
Carlos
Fwd: Fwd: Copy versioned nodes
Posted by David Nuescheler <da...@gmail.com>.
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 <ge...@us.ibm.com>
Date: Mar 3, 2006 1:38 PM
Subject: Re: Fwd: Copy versioned nodes
To: david.nuescheler@day.com
Cc: jackrabbit-dev@incubator.apache.org
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.
Re: Fwd: Copy versioned nodes
Posted by Geoffrey M Clemm <ge...@us.ibm.com>.
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" <da...@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.
Re: Fwd: Copy versioned nodes
Posted by Geoffrey M Clemm <ge...@us.ibm.com>.
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.
Cheers,
Geoff
"David Nuescheler" <da...@gmail.com> wrote on 03/03/2006
04:43:22 AM:
> 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
Re: Fwd: Copy versioned nodes
Posted by Thomas Heute <th...@jboss.org>.
Thanks again for your advice and interest David. (plus the good work)
On Friday 03 March 2006 12.49, David Nuescheler wrote:
> hi thomas,
>
> > I think there are use cases to keep history *and* to "forget" history.
> > What would be nice is to let do both.
>
> agreed. and in the context of multiple workspaces both is possible.
> clone() keeps the history, copy() doesn't
>
> looking at your use case i would really recommend to have at least two
> workspaces. in my opinion your use case is exactly what workspaces
> are intended to be used for.
> > 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.
>
> well, your use case is certainly a frequent one. i doubt that copying
> the version history is necessary to accomplish what you would like
> to achieve.
>
> regardless, i find the topic of being able to copy a version history
> is worth a discussion in the jsr-283 expert group and therefore take
> all the input from this mailing list into the jsr-283 expert group.
> regards,
> david
Re: Fwd: Copy versioned nodes
Posted by Cédric Damioli <ce...@anyware-tech.com>.
Hi,
David Nuescheler a écrit :
> ...
> regardless, i find the topic of being able to copy a version history
> is worth a discussion in the jsr-283 expert group and therefore take
> all the input from this mailing list into the jsr-283 expert group.
>
> regards,
> david
>
This thread about versioning stuff bring me back to another one :
http://mail-archives.apache.org/mod_mbox/incubator-jackrabbit-dev/200506.mbox/%3c42A9B4D4.1050806@anyware-tech.com%3e
which contained questions but finally no answers. I may be more lucky
this year :-) :
1) How to remove a VersionHistory ? Tobias opened the JIRA issue
JCR-134, and I proposed to introduce a
VersionManager.removeVersionHistory(history) or VersionHistory.remove()
which would fail if any Node in any worspace still references the given
VersionHistory, and remove all Versions and the VersionHistory itself
otherwise.
2) How to get the VersionHistory of any deleted Node (to simulate the
"Attic" in the CVS world). Would it be possible to "flag" a
VersionHistory when no Node in any workspace references it ? It would
help to restore a Node, without initially knowing anything about it
(UUID, path, type, ...)
2a) An extension to the above point is to be able to retrieve a Version
based on a Date : something like VersionHistory.getVersionByDate(Calendar)
2b) As I also pointed out in that old thread, for primary-type based
search, I can't understand why the jcr:frozenPrimaryType is only held by
each jcr:frozenNode and not only once by the VersionHistory, as I think
that the primary type of a given Node cannot change during its whole
life. But I may miss something here.
Back in June, 2005, when these points have been discussed on this list,
jsr-283 did not exist, and I'm not even sure that jsr-170 was final.
So the expert group may be now interested in such small thoughts about
versioning stuff :-)
WDYT about this ?
Regards,
--
Cédric Damioli
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com
Re: Fwd: Copy versioned nodes
Posted by David Nuescheler <da...@gmail.com>.
hi thomas,
> I think there are use cases to keep history *and* to "forget" history.
> What would be nice is to let do both.
agreed. and in the context of multiple workspaces both is possible.
clone() keeps the history, copy() doesn't
looking at your use case i would really recommend to have at least two
workspaces. in my opinion your use case is exactly what workspaces
are intended to be used for.
> 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.
well, your use case is certainly a frequent one. i doubt that copying
the version history is necessary to accomplish what you would like
to achieve.
regardless, i find the topic of being able to copy a version history
is worth a discussion in the jsr-283 expert group and therefore take
all the input from this mailing list into the jsr-283 expert group.
regards,
david
Re: Fwd: Copy versioned nodes
Posted by Paco Avila <pa...@git.es>.
El vie, 03-03-2006 a las 13:14 +0100, Martin Perez escribió:
> I do not think that you are the only one that needs that. I will see awesome
> to have the choice to explicitly tell Jackrabbit if he should copy/do not
> copy the version history of a node hierarchy.
This is flexibility :)
The other way is to use a clone(copy the last document version and all
its history) or copy(only copy the last document version) method.
--
Paco Avila
GIT Consultors
Re: Fwd: Copy versioned nodes
Posted by Martin Perez <mp...@gmail.com>.
On 3/3/06, Thomas Heute <th...@jboss.org> wrote:
>
>
> 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.
I cannot agree more!
That said, if i am the only one who needs that, it does not worth the pain.
>
>
I do not think that you are the only one that needs that. I will see awesome
to have the choice to explicitly tell Jackrabbit if he should copy/do not
copy the version history of a node hierarchy.
Martin
Re: Fwd: Copy versioned nodes
Posted by Thomas Heute <th...@jboss.org>.
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 <da...@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
Re: Fwd: Copy versioned nodes
Posted by Carlos Villegas <ca...@uniscope.jp>.
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 <da...@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
>>
>
>
Re: Fwd: Copy versioned nodes
Posted by Martin Perez <mp...@gmail.com>.
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 <da...@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
>
Re: Fwd: Copy versioned nodes
Posted by David Nuescheler <da...@gmail.com>.
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
Re: Fwd: Copy versioned nodes
Posted by Carlos Villegas <ca...@uniscope.jp>.
When you copy a versionable node in jackrabbit, is its version history
reset? I mean the new node starts with a fresh version history?
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. 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.
Carlos
David Nuescheler wrote:
> hi thomas,
>
> i think this is an interesting usecase that you mention.
>
> clearly jcr does not expect such an operation, and i have to admit
> in my experience (cms) it was never necessary to copy the version
> history. also, since geoff clemm as the main driver of the versioning
> portion of the jcr spec has never mentioned such a need, despite
> his extensive background in config management, i wonder if
> this has a deeper reason.
>
> how would you achieve that in cvs or svn, i dont think there is a
> straight forward way either.
>
> any thoughts?
>
> regards,
> david
>
Fwd: Copy versioned nodes
Posted by David Nuescheler <da...@gmail.com>.
hi thomas,
i think this is an interesting usecase that you mention.
clearly jcr does not expect such an operation, and i have to admit
in my experience (cms) it was never necessary to copy the version
history. also, since geoff clemm as the main driver of the versioning
portion of the jcr spec has never mentioned such a need, despite
his extensive background in config management, i wonder if
this has a deeper reason.
how would you achieve that in cvs or svn, i dont think there is a
straight forward way either.
any thoughts?
regards,
david
Re: Copy versioned nodes
Posted by Thomas Heute <th...@jboss.org>.
Thanks a lot for the explanations and confirmation.
Have a nice day.
On Friday 03 March 2006 08.41, Tobias Bocanegra wrote:
> hi thomas,
> versions are not automatically copied.and you are correct, this is not
> defined by the spec, because the idea is, that by copying your create
> a new instance of a node, not a backup.
> so, you need to do it yourself. the problem is, that versions cannot
> be copied, since the entire version storage is read-only. so what you
> need to do is to restore all versions of the original node, copy them
> over to your new node, and check them in, one-by-one.
>
> regards, toby
>
> On 3/2/06, Thomas Heute <th...@jboss.org> wrote:
> > Hello,
> >
> > I am trying to copy versionable nodes using workspace.copy([...]) with
> > the 0.9 version of JackRabbit
> >
> > From what i experienced, only the latest revision seems to get copied.
> > This is unfortunately not defined by the spec.
> > What i would need is to copy all the versions or a version with a certain
> > tag.
> >
> > Could you please confirm that i need to do the copy by myself ? Or should
> > we change the way it is implemented in jackRabbit ? (Or did i miss
> > something since i am fairly new with JSR 170/JackRabbit.
> >
> >
> > Thanks in advance and thanks for the good work,
> > Thomas.
>
> --
> -----------------------------------------< tobias.bocanegra@day.com >---
> Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com >---
Re: Copy versioned nodes
Posted by Tobias Bocanegra <to...@day.com>.
hi thomas,
versions are not automatically copied.and you are correct, this is not
defined by the spec, because the idea is, that by copying your create
a new instance of a node, not a backup.
so, you need to do it yourself. the problem is, that versions cannot
be copied, since the entire version storage is read-only. so what you
need to do is to restore all versions of the original node, copy them
over to your new node, and check them in, one-by-one.
regards, toby
On 3/2/06, Thomas Heute <th...@jboss.org> wrote:
>
> Hello,
>
> I am trying to copy versionable nodes using workspace.copy([...]) with the 0.9
> version of JackRabbit
>
> From what i experienced, only the latest revision seems to get copied.
> This is unfortunately not defined by the spec.
> What i would need is to copy all the versions or a version with a certain tag.
>
> Could you please confirm that i need to do the copy by myself ? Or should we
> change the way it is implemented in jackRabbit ? (Or did i miss something
> since i am fairly new with JSR 170/JackRabbit.
>
>
> Thanks in advance and thanks for the good work,
> Thomas.
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---