jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukas Kahwe Smith <...@pooteeweet.org>
Subject workspace mirroring
Date Fri, 13 Apr 2012 13:12:29 GMT

I have brought this up before on the JSR-333 list.
The term "mirroring" isnt ideal, but the concept is essentially is to make it easy to clone
a workspace and keep it in sync with changes happening in the source workspace.
This would allow users to essentially use workspaces as personal play grounds.
Obviously this can lead to incompatible changes, which imho should just leave the nodes in
a temporarily broken state, that needs to be fixed manually (similarly to how CouchDB deals
with such cases).


User 1 wants to work on some content changes.

1) mirror a given workspace X as X_1 (this actually does not do any copying .. all it does
is create a new workspace, but no data is actually copied, but browsing workspace X_1 is effectively
the same as browsing X
2) changes are done to workspace X and immediately also appear in workspace X_1
3) a change to path /foo/bar is done in X_1 .. at this point the data for /foo/bar is copied
from workspace X along with the changes that were made
4) changes to other nodes are done in workspace X and immediately also appear in workspace
5) user 1 decides to merge the changes to /foo/bar back to workspace X and kills workspace

Typo3 (and afaik Midgard) as this feature.
For some new graphs with how this work see the following slides (starting at slide 13):

The key here is that 1) doing this mirror command is cheap 2) changes from the source automatically
appear in the target workspace.

1) requires that there is a way to do clone's with copy on write while 2) could in theory
be emulated somewhat (at least if there arent too many changes in the source repo) via observers

Is that something that could be natively provided in Oak?
I do believe it would also be great of this could become an optional feature in JSR-333

Lukas Kahwe Smith

View raw message