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
