jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: JSR-170 clarification - workspaces, branching, etc.
Date Sun, 29 May 2005 18:36:31 GMT
hi miro

thanks for your questions...

> Not sure if this is the right forum to be asking this - if not, please
> could someone direct me to the right list?
i think this is a good forum.

> Tags, it appears would be implemented as version labels, so to tag the
> current state of the entire content tree as belonging to a new
> release, the base version of the content tree root node and every node
> below it would have a new label applied to it for that release. To
> retrieve this content, it would be necessary to traverse the content
> tree, and for every node call getVersionByLabel on its version
> history. Is that correct?
yes

> How about branching? What I'm looking for here is to be able to create
> a new tree that includes all of the nodes in the original tree, where
> by default each node "inherits" the state of its corresponding node in
> the tree from which it was branched. Once a change is made to a node
> in the branched tree, the version histories would diverge.
> From my understanding of the spec, this would be achieved by creating
> a new workspace for the new branch (can this be done
> programmatically?), then cloning or updating the root node of the
> content tree into the new empty workspace (is there a difference in
> this case between the behaviour of cloning and updating?). Each node
> in the new workspace would then share the same version history as the
> original workspace nodes, but the different workspaces would have
> different base versions for that node, so when the node was modified
> (a new version created) in the original workspace, this would not be
> visible in the new workspace.
that's correct too...

the workspace management methods (create a new workspace, etc.) 
are available in jackrabbit, but have been excluded from jcr v1.0

it has to be said that you don't have to have multiple workspaces
to branch a version history, a restore and check-out for example
will do

> In order for the nodes in the new workspace to "inherit" the state of
> the nodes in the original workspace, the node trees must be merged.
> This would then cause the base version in the new workspace to be
> updated to reflect the old workspace.
> If, in the meantime, the node in the new workspace had been altered
> (versioned), then there would be a branch in the version graph, and
> the merge operation would fail for that node, allowing the application
> to chosoe whether to keep them seperate or attempt to resolve the
> conflict programmatically.
> 
> Is any of that lot correct? 
everything so far...

> It seems like quite a lot would depend on
> the efficiency of some of these operations (in particular, merge, as
> it would need to be called every time a branched content set needed to
> be viewed). 
really? i don't really see that.
for example, let's say you have a release 1.0 and a 
release 2.0 of a piece of software in your repository then i 
would probably assume a workspace per "release". 
in my mind the merge() would only be called if a developer 
patches release 1.0 and would also need to apply it to release
2.0 on node that already experienced a check-in for 2.0?

in my mind that should not happen to frequently. please
apologize if i misunderstood your comment...

> How much have people used these features in anger? Are
> there any examples out there?
i don't know whether in anger or not ;), but jackrabbit certainly
implements all of the features and an example of
a version graph can be found here:
http://jsr170tools.day.com/crx/ui/versionbrowse.jsp?Path=/math.xml[3]

for manipulations you will have to login (admin/admin) here:
http://jsr170tools.day.com/crx/login.jsp

personally, i think that the "content explorer" usually helps quite bit
to wrap your head around the spec.

regards,
david

Mime
View raw message