jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Anderson <t...@urchin.earth.li>
Subject Re: New to JCR (again) and mildly baffled by workspaces
Date Mon, 09 May 2011 18:20:29 GMT
On Sun, 8 May 2011, Justin Edelson wrote:

> On Sun, May 8, 2011 at 12:32 PM, Tom Anderson <twic@urchin.earth.li> wrote:
>> Marcel Reutegger wrote:
>>  you can look at workspaces as local checkouts of a revision control
>>  system.
>> That's a really useful metaphor, because i understand revision control 
>> systems. However, i don't understand how the parts map on to JCR. The 
>> workspace corresponds to a local working copy, right? So what's the 
>> equivalent of the central repository? What are the equivalents of 
>> updating and committing? How about branching and merging?
> I think you're taking the metaphor a bit too literally.

One of the dangers of metaphors!

> It might be easier to think of workspaces as branches. You'd designate a 
> single workspace (probably "default") as the "trunk" workspace. In this 
> context, Node.update() could handle both "commit" and "update" 
> operations; Workspace.createWorkspace(name, srcWorkspace) is the 
> "branch" operation and VersionManager.merge() is the "merge" operation.

To be picky, i think that's still a badly-fitting metaphor, because update 
moves changes from one workspace to another, which here would mean moving 
across branches, whereas commit/update in CVS and friends affect a single 
branch. The thing is that in this metaphor, there is no working copy. 
Unless the changes in memory are the working copy, and 
Session.save()/Session.refresh(true) are commit and update?

Maybe i should give up on the metaphors.

About update() - it works if the node whose content i want to propagate 
from one workspace to another already exists in the destination. What do i 
do if it doesn't? Workspace.clone()?

If i have a node which exists in two workspaces, but where both have some 
content i want to keep (different child nodes, for instance), is there any 
way i can use update (and/or clone) to do that? Or is this where i need to 
use VersionManager.merge? Do i need to be using versioning for that?

>> I see from the javadoc that there are methods checkin, checkout, and 
>> merge - but that these are (as of JCR 2.0) on the VersionManager. That 
>> suggests to me that if i'm going to use them, i'm also going to be 
>> getting involved with versions. Is that the case? Are workspaces and 
>> versioning inextricably linked? Can i use workspaces without 
>> versioning? Can i use versioning without workspaces?
> checkin/checkout have nothing to do with workspaces.


> If you're going to be using workspaces as branches, then yes, you'll 
> need to use versioning at some level (especially for merge operations).

Okay. This sounds like something i need to understand; is there something 
i can read which walks through the process of using workspaces this way, 
or in some related way from which i can build? Or is there any software 
whose source code i can read to learn more about this?

> You can use workspaces without versioning. You can use versioning 
> without workspaces.

Okay, thanks. I wonder if it might be simplest for me to use a single 
workspace with multiple versions, actually. Would it be plausible to have 
a style where each client did something like:

1. Get a session
2. Get the root node
3. Check it out (so creating a new version?)
4. Do all sorts of work, but always relative to the root node
5. Check the root node in
6. Do merging as necessary to restore a single head

? Or is that completely misunderstanding how versioning works?


Initial thoughts - who cares? Subsequent thoughts - omg!!! (Female, 14,
Scotland) -- 4.5 million young Brits' futures could be compromised by
their electronic footprint, Information Commissioner's Office
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message