Hi Jukka,
Copying all workspaces into another repository was the initial idea. I
changed my approach because of the data format issue: it is possible a PM
switch format and break backward compatibility where the export system view
will be always valid.
The export system view will be compressed so most of the overhead is CPU +
RAM based.
You have far more experience than me on JR, if you think working on the
persistence manager is way better, I'll do it this way. Please tell me :)
Nico
On 7/27/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi,
On 7/26/06, Nicolas <[EMAIL PROTECTED]> wrote:
> I am wondering how to backup the Version History. Since VersionManager
looks
> a lot like a Workspace, I was thinking of instantiating the content as a
> workspace (basically parsing the Versioning tag as a workspace one) and
then
> backupping the workspace using my existing class.
>
> 1/ repo.createWorkspace("temp", myXml);
> 2/ Backup the temp workspace
> 3/ Backup NodeType + Namespace
> 4/ Destroy the temp wsp.
>
> Did I miss anything? What do you think? Can it work? Do you see any
unwanted
> side effect?
I'd very much prefer if the backup tool didn't need to write anything
to the repository being backed up.
The versioning store in Jackrabbit is backed up by a normal
persistence manager, so my approach would be to reach directly to the
PersistenceManager instance and backup/restore the versioning content
directly on that level. My initial idea was that this would be the
best level also for backing up and restoring normal workspaces. This
way you can avoid the system view overhead and have and be able to
restore the version histories without trouble.
But if you want to stick with using the system view export, then I
think the best way to backup the version histories is to get a system
view export of /jcr:system/jcr:versionStorage. This subtree is shared
by all workspaces and contains all the version histories in the
repository.
Note also that if you use the system view to backup normal
repositories, you should come up with a way to explicitly exlude
/jcr:system from the export, as that's a virtual tree shared by all
workspaces.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED]
Software craftsmanship, JCR consulting, and Java development
--
a+
Nico
my blog! http://www.deviant-abstraction.net !!
