jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miro Walker <miro.wal...@gmail.com>
Subject JSR-170 clarification - workspaces, branching, etc.
Date Fri, 27 May 2005 18:19:18 GMT

Not sure if this is the right forum to be asking this - if not, please
could someone direct me to the right list?

I'm trying to get my head around the spec and I'm struggling to map
some of the concepts in the spec into real-world examples. Can someone
help? In particular, workspaces and branched version graphs are
confusing me. I think I may have it, but I want to make sure I'm not

For example, if one were to attempt to implement a source control
system such as subversion on top of jackrabbit, or any jsr-170
repository (has anyone done this?), then how would the concepts of
branches, tagged releases, etc. be implemented in a repository? I'll
try to write out what I understand, and if anyone could tell me where
I've misunderstood, I'd really appreciate it.

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?

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.

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? 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). How much have people used these features in anger? Are
there any examples out there?

Many thanks,


View raw message