Hi, 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).
Example: 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 X_1 5) user 1 decides to merge the changes to /foo/bar back to workspace X and kills workspace X_1 Typo3 (and afaik Midgard) as this feature. For some new graphs with how this work see the following slides (starting at slide 13): http://www.slideshare.net/kfish/typo3-cr-in-phoenix 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 regards, Lukas Kahwe Smith [email protected]
