isCheckedOut(String absPath)
Returns true if the node at absPath is either
versionable (full or simple) and currently checked-out,
non-versionable and its nearest versionable ancestor is checked-out or
non-versionable and it has no versionable ancestor.

checkin

Creates for the versionable node at absPath a new version
with a system generated version name and returns that version (which will
be the new base version of this node). Sets the jcr:checkedOut
property to false thus putting the node into the checked-in state.
This means that the node and its connected non-versionable subtree
become read-only. A node's connected non-versionable subtree is the set
of non-versionable descendant nodes reachable from that node through
child links without encountering any versionable nodes. In other words,
the read-only status flows down from the checked-in node along every
child link until either a versionable node is encountered or an item with
no children is encountered. In a system that supports only simple
versioning the connected non-versionable subtree will be equivalent to
the whole subtree, since simple-versionable nodes cannot have
simple-versionable descendants.

If the node is already checked-in, this method has no effect but returns
the current base version of the node at absPath.

If the node at absPath is not versionable, an
UnsupportedRepositoryOperationException is thrown.

A VersionException is thrown or if a child item of this node
has an OnParentVersion status of ABORT. This
includes the case where an unresolved merge failure exists on this node,
as indicated by the presence of the jcr:mergeFailed
property.

If there are unsaved changes pending on the node at absPath,
an InvalidItemStateException is thrown.

Throws a LockException if a lock prevents the operation.

If checkin succeeds, the change to the
jcr:isCheckedOut property is automatically persisted (there
is no need to do an additional save).

VersionException - if jcr:predecessors does
not contain at least one value or if a
child item of the node at absPath
has an OnParentVersion
status of ABORT. This
includes the case where an unresolved
merge failure exists on the node, as
indicated by the presence of a
jcr:mergeFailed property.

checkout

Sets the versionable node at absPath to checked-out status
by setting its jcr:isCheckedOut property to
true. Under full versioning it also sets the
jcr:predecessors property to be a reference to the current
base version (the same value as held in jcr:baseVersion).

This method puts the node into the checked-out state, making it
and its connected non-versionable subtree no longer read-only (see VersionManager.checkin(String) for an explanation of the term "connected
non-versionable subtree". Under simple versioning this will simply be the
whole subtree).

If successful, these changes are persisted immediately, there is no need
to call save.

If the node at absPath is already checked-out, this method
has no effect.

If the node at absPath is not
versionable, an UnsupportedRepositoryOperationException is
thrown.

checkpoint

Performs a checkin() followed by a checkout()
on the versionable node at absPath.

If the node is already checked-in, this method is equivalent to
checkout().

If the node at absPath is not versionable, an
UnsupportedRepositoryOperationException is thrown.

A VersionException is thrown if a child item of the node at
absPath has an OnParentVersion of
ABORT. This includes the case where an unresolved merge
failure exists on the node, as indicated by the presence of the
jcr:mergeFailed property.

If there are unsaved changes pending on the node at absPath,
an InvalidItemStateException is thrown.

VersionException - if a child item of the node at
absPath has an
OnParentVersion of
ABORT. This includes the
case where an unresolved merge failure
exists on the node, as indicated by the
presence of the jcr:mergeFailed.

restore

Restores a set of versions at once. Used in cases where a "chicken and
egg" problem of mutually referring REFERENCE properties
would prevent the restore in any serial order.

If the restore succeeds the changes made to the corresponding node are
persisted immediately, there is no need to call save.

The following restrictions apply to the set of versions specified:

If S is the set of versions being restored simultaneously,

For every version V in S that
corresponds to a missing node, there must also be a parent of V in
S.

S must contain at least one version that
corresponds to an existing node in the workspace.

No V in S can be a root version
(jcr:rootVersion).

If any of these restrictions does not hold, the restore will fail because
the system will be unable to determine the path locations to which one or
more versions are to be restored. In this case a VersionException
is thrown.

The versionable nodes in the current workspace that correspond to the
versions being restored define a set of (one or more) subtrees. An
identifier collision occurs when the current workspace contains a node
outside these subtrees that has the same identifier as one of the
nodes that would be introduced by the restore operation
into one of these subtrees. The result in such a case is governed
by the removeExisting flag. If removeExisting
is true then the incoming node takes precedence, and the
existing node (and its subtree) is removed. If removeExisting
is false then a ItemExistsException is thrown
and no changes are made. Note that this applies not only to cases where
the restored node itself conflicts with an existing node but also to
cases where a conflict occurs with any node that would be introduced into
the workspace by the restore operation. In particular, conflicts
involving subnodes of the restored node that have
OnParentVersion settings of COPY or
VERSION are also governed by the removeExisting
flag.

An UnsupportedRepositoryOperationException is thrown if one
or more of the nodes to be restored is not versionable.

An InvalidItemStateException is thrown if this
Session has pending unsaved changes.

VersionException - if the set of versions to be restored
is such that the original path location
of one or more of the versions cannot
be determined or if the restore
would change the state of a existing
versionable node that is currently
checked-in or if a root version
(jcr:rootVersion) is among
those being restored.

restore

Restores the node at absPath to the state defined by the
version with the specified versionName.

If the node at absPath is not versionable, an
UnsupportedRepositoryOperationException is thrown.

If successful, the change is persisted immediately and there is no need
to call save.

A VersionException is thrown if no version with the
specified versionName exists in the node's version history
or if an attempt is made to restore the root version
(jcr:rootVersion).

An InvalidItemStateException is thrown if this Session (not
necessarily this Node) has pending unsaved changes.

A LockException is thrown if a lock prevents the addition of the mixin.

This method will work regardless of whether the node at
absPath is checked-in or not.

An identifier collision occurs when a node exists outside the subtree
rooted at this node with the same identifier as a node that would be
introduced by the restore operation into the subtree at
this node. The result in such a case is governed by the
removeExisting flag. If removeExisting is
true, then the incoming node takes precedence, and the
existing node (and its subtree) is removed (if possible; otherwise a
RepositoryException is thrown). If removeExisting
is false, then a ItemExistsException is thrown
and no changes are made. Note that this applies not only to cases where
the restored node itself conflicts with an existing node but also to
cases where a conflict occurs with any node that would be introduced into
the workspace by the restore operation. In particular, conflicts
involving subnodes of the restored node that have
OnParentVersion settings of COPY or
VERSION are also governed by the removeExisting
flag.

restore

Restores the specified version and the changes the
corresponding node to reflect the state defined by the specified
version.

If the node at absPath is not versionable, an
UnsupportedRepositoryOperationException is thrown.

If successful, the change is persisted immediately and there is no need
to call save.

A VersionException is thrown if the specified
version is not part of this node's version history or if an
attempt is made to restore the root version (jcr:rootVersion).

An InvalidItemStateException is thrown if this Session (not
necessarily the Node at absPath) has pending
unsaved changes.

A LockException is thrown if a lock prevents the restore.

This method will work regardless of whether the node at
absPath is checked-in or not.

An identifier collision occurs when a node exists outside the subtree
rooted at this node with the same identifier as a node that would be
introduced by the restore operation into the subtree at
this node. The result in such a case is governed by the
removeExisting flag. If removeExisting is
true, then the incoming node takes precedence, and the
existing node (and its subtree) is removed (if possible; otherwise a
RepositoryException is thrown). If removeExisting
is false, then a ItemExistsException is thrown
and no changes are made. Note that this applies not only to cases where
the restored node itself conflicts with an existing node but also to
cases where a conflict occurs with any node that would be introduced into
the workspace by the restore operation. In particular, conflicts
involving subnodes of the restored node that have
OnParentVersion settings of COPY or
VERSION are also governed by the removeExisting
flag.

VersionException - if the specified version
does not have a corresponding node in
the workspace this
VersionManager has been created for or
if an attempt is made to restore the
root version (jcr:rootVersion).

restore

A node need not exist at absPath, though the parent of
absPath must exist, otherwise a PathNotFoundException
is thrown.

If a node does exist at absPath then it must correspond to the
version being restored (the version must be a version of that
node) and must not be a root version (jcr:rootVersion),
otherwise a VersionException is thrown.

If no node exists at absPath then a VersionException
is thrown if the parent node of absPath is versionable and
checked-in or is non-versionable but its nearest versionable ancestor is
checked-in.

If there is a node at absPath then the checked-in
status of that node itself and the checked-in status of its parent are
irrelevant. The restore will work even if one or both are checked-in.

An identifier collision occurs when a node exists outside the subtree
rooted at absPath with the same identifier as a node
that would be introduced by the restore operation into
the subtree at absPath. The result in such a case is
governed by the removeExisting flag. If
removeExisting is true, then the incoming node
takes precedence, and the existing node (and its subtree) is removed (if
possible; otherwise a RepositoryException is thrown). If
removeExisting is false, then a
ItemExistsException is thrown and no changes are made. Note
that this applies not only to cases where the restored node itself
conflicts with an existing node but also to cases where a conflict occurs
with any node that would be introduced into the workspace by the restore
operation. In particular, conflicts involving subnodes of the restored
node that have OnParentVersion settings of COPY
or VERSION are also governed by the removeExisting
flag.

If the would-be parent of the location absPath is actually a
property, or if a node type restriction would be violated, then a
ConstraintViolationException is thrown.

If the restore succeeds, the changes made to this node are
persisted immediately, there is no need to call save.

An InvalidItemStateException is thrown if this Session (not
necessarily this Node) has pending unsaved changes.

An UnsupportedRepositoryOperationException is thrown if
versioning is not supported.

ConstraintViolationException - If the would-be parent of the
location absPath is
actually a property, or if a node
type restriction would be violated

VersionException - if the parent node of absPath
is versionable and checked-in or is
non-versionable but its nearest
versionable ancestor is checked-in
or if a node exists at absPath that
is not the node corresponding to the
specified version or if
an attempt is made to restore the
root version (jcr:rootVersion).

restoreByLabel

Restores the version of the node at absPath with the
specified version label. If this node is not versionable, an
UnsupportedRepositoryOperationException is thrown. If
successful, the change is persisted immediately and there is no need to
call save.

A VersionException is thrown if the specified
versionLabel does not exist in this node's version history.

An InvalidItemStateException is thrown if this Session (not
necessarily Node at absPath) has pending
unsaved changes.

A LockException is thrown if a lock prevents the restore.

This method will work regardless of whether the node at
absPath is checked-in or not.

An identifier collision occurs when a node exists outside the subtree
rooted at this node with the same identifier as a node that would be
introduced by the restoreByLabel operation into the
subtree at this node. The result in such a case is governed by the
removeExisting flag. If removeExisting is
true, then the incoming node takes precedence, and the
existing node (and its subtree) is removed (if possible; otherwise a
RepositoryException is thrown). If removeExisting
is false, then a ItemExistsException is thrown
and no changes are made. Note that this applies not only to cases where
the restored node itself conflicts with an existing node but also to
cases where a conflict occurs with any node that would be introduced into
the workspace by the restore operation. In particular, conflicts
involving subnodes of the restored node that have
OnParentVersion settings of COPY or
VERSION are also governed by the removeExisting
flag.

merge

It recursively tests each versionable node in the subtree of the node at
absPath against its corresponding node in
srcWorkspace with respect to the relation between their
respective base versions and either updates the node in question or not,
depending on the outcome of the test.

A MergeException is thrown if bestEffort is
false and a versionable node is encountered whose
corresponding node's base version is on a divergent branch from this
node's base version.

If successful, the changes are persisted immediately, there is no need to
call save.

This method returns a NodeIterator over all versionable
nodes in the subtree that received a merge result of fail. If
bestEffort is false, this iterator will be
empty (since if merge returns successfully, instead of
throwing an exception, it will be because no failures were encountered).
If bestEffort is true, this iterator will
contain all nodes that received a fail during the course of this
merge operation.

If the specified srcWorkspace does not exist, a
NoSuchWorkspaceException is thrown.

If the current session does not have sufficient permissions to perform
the operation, then an AccessDeniedException is thrown.

An InvalidItemStateException is thrown if this session (not
necessarily this Node) has pending unsaved changes.

merge

If isShallow is true, it tests this versionable
node against its corresponding node in srcWorkspace with
respect to the relation between their respective base versions and either
updates the node in question or not, depending on the outcome of the
test.

If isShallow is false, it recursively tests
each versionable node in the subtree as mentioned above.

If isShallow is true and this node is not
versionable, then this method returns and no changes are made.

A MergeException is thrown if bestEffort is
false and a versionable node is encountered whose
corresponding node's base version is on a divergent branch from the base
version of the node at absPath.

If successful, the changes are persisted immediately, there is no need to
call save.

This method returns a NodeIterator over all versionable
nodes in the subtree that received a merge result of fail. If
bestEffort is false, this iterator will be
empty (since if merge returns successfully, instead of
throwing an exception, it will be because no failures were encountered).
If bestEffort is true, this iterator will
contain all nodes that received a fail during the course of this
merge operation.

If the specified srcWorkspace does not exist, a
NoSuchWorkspaceException is thrown.

If the current session does not have sufficient permissions to perform
the operation, then an AccessDeniedException is thrown.

An InvalidItemStateException is thrown if this session (not
necessarily the node at absPath) has pending unsaved
changes.

This node will be updated to
the state of its correspondee (if the base version of the correspondee is
more recent in terms of version history)

This node will be
left alone (if this node's base version is more recent in terms of
version history).

This node will be marked as having failed
the merge test (if this node's base version is on a different branch of
the version history from the base version of its corresponding node in
the other workspace, thus preventing an automatic determination of which
is more recent).

In the last case the merge of the non-versionable subtree (the "content")
of this node must be done by the application (for example, by providing a
merge tool for the user).

Additionally, once the content of the nodes has been merged, their
version graph branches must also be merged. The JCR versioning system
provides for this by keeping a record, for each versionable node that
fails the merge test, of the base version of the corresponding node that
caused the merge failure. This record is kept in the
jcr:mergeFailed property of this node. After a
merge, this property will contain one or more (if multiple
merges have been performed) REFERENCEs that point to the
"offending versions".

To complete the merge process, the client calls doneMerge(Version
v) passing the version object referred to be the
jcr:mergeFailed property that the client wishes to connect
to this node in the version graph. This has the effect of
moving the reference to the indicated version from the
jcr:mergeFailed property of this node to the
jcr:predecessors.

If the client chooses not to connect this node to a particular version
referenced in the jcr:mergeFailed property, he calls VersionManager.cancelMerge(String, Version). This has the effect of removing the
reference to the specified version from
jcr:mergeFailedwithout adding it to
jcr:predecessors.

Once the last reference in jcr:mergeFailed has been either
moved to jcr:predecessors (with doneMerge) or
just removed from jcr:mergeFailed (with
cancelMerge) the jcr:mergeFailed property is
automatically removed, thus enabling this node to be
checked-in, creating a new version (note that before the
jcr:mergeFailed is removed, its OnParentVersion
setting of ABORT prevents checkin). This new version will
have a predecessor connection to each version for which
doneMerge was called, thus joining those branches of the
version graph.

If successful, these changes are persisted immediately, there is no need
to call save.

A VersionException is thrown if the version
specified is not among those referenced in this node's
jcr:mergeFailed property.

If there are unsaved changes pending on this node, an
InvalidItemStateException is thrown.

An UnsupportedRepositoryOperationException is thrown if this
node is not versionable.

createConfiguration

Calling createConfiguration on the node N at
absPath creates, in the configuration storage, a new
nt:configuration node whose root is N. A reference to
N is recorded in the jcr:root property of the new
configuration, and a reference to the new configuration is recorded in
the jcr:configuration property of N.

If the specified baseline is null, a new
version history is created to store baselines of the new configuration,
and the jcr:baseVersion of the new configuration references
the root of the new version history. If the specified baseline is not
null, the jcr:baseVersion of the new
configuration references the specified baseline.

The changes are persisted immediately, a save is not
required.

An UnsupportedRepositoryOperationException is thrown if
N is not versionable.

setActivity

This method is called by the client to set the current activity on the
session from which this version manager has been obtained. Changing the
current activity is done by calling setActivity again.
Cancelling the current activity (so that the session has no current
activity) is done by calling setActivity(null). The activity
Node is returned.

An UnsupportedRepositoryOperationException is thrown if the
repository does not support activities or if activity is not
a nt:activity node.

merge

This method merges the changes that were made under the specified
activity into the current workspace.

An activity A will be associated with a set of versions through the
jcr:activity reference of each version node in the set.
We call each such associated version a member of A.

For each version history H that contains one or more members of
A, one such member will be the latest member of A in H.
The latest member of A in H is the version in H that
is a member of A and that has no successor versions (to any degree)
that are also members of A.

The set of versions that are the latest members of A in their
respective version histories is called the change set of A. It
fully describes the changes made under the activity A.

This method performs a shallow merge into the current workspace of each version
in the change set of the activity specified by activityNode.
If there is no corresponding node in this workspace for a given member of
the change set, that member is ignored.

This method returns a NodeIterator over all versionable
nodes in the subtree that received a merge result of fail.

A VersionException is thrown if the specified node is not
an nt:activity node.