Re: checkin-set

Werner wrote on 04/12/2006 09:17:40 AM:

> If activities and workspaces are used together to implement branches,

Actually, only activities are needed to implement branches (each branch
is an activity).  To manipulate branches, you need a workspace (since
you normally add versions to branches by checking out a VCR against a 
given
activity, and then checking in to create a new version in that 
branch/activity).

> each branch could be checked out if there is a workspace,

You don't checkout a branch/activity ... you checkout a VCR against a 
branch/activity.

> which has a VCR, that is linked to the first version of that branch.

Not sure what you mean by "linking the VCR to the first version of that
branch".  The VCR is linked to a branch/activity by being checked-out 
against 
that branch/activity, which will set the DAV:activity-set of that VCR to 
reference
that branch/activity.
 
> If I now want to do a check out in a branch I need to locate the
> correct VCR.

You locate the correct VCR by knowing the pathname of that VCR relative
to the root of your workspace.  So if you want to checkout src/foo.c
in workspace http://my.server/ws/myws, you would checkout
http://my.server/ws/myws/src/foo.c.

You indicate what branch/activity you are working on by setting the
DAV:current-activity of your workpspace to reference that branch/activity.

> Since the branches are visible in the version tree,

A version has a DAV:activity-set property which indicates
what branch/activity it is in.  Is that what you mean by "visible
in the version tree"?

> the
> obvious point for a check-out is the last checked-in version on the
> branch. However, a version can't be used as the request URL of the
> CHECKOUT method.

You checkout whatever is the current checked-in version of the
VCR with the appropriate pathname in your workspace.  If it is
not selecting the last checked-in version (or a successor of the last
checked-in version) in that branch/activity, then the CHECKOUT will fail
because it violates the DAV:linear-activity pre-condition (unless you
have set DAV:unreserved on the VCR, in which case you will be allowed
to CHECKOUT, but the CHECKIN will fail, with a DAV:linear-activity
precondition failure).
 
> How can I find the correct VCR given a version and knowing in which
> workspace I want to do it?

The client has to specify the pathname of the VCR they want to checkout,
from which the system can infer the workspace (the DAV:workspace property
of the VCR).  If you want to checkout a particular version, then you
UPDATE the VCR to be that version before you issue the CHECKOUT (remember,
this is *your* workspace).

> If a version had a checkin-set, analogous to the checkout-set,
> all VCRs could be obtained that have the version
> as the checked-in version. 

In a distributed implementation, you don't know all the workspaces 
that are currently looking at a particular version ... there could be
thousands, on many servers (in a distributed system, the version
history is often not on the same server as the workspace).
So we don't require that a WebDAV server maintain this information.

> Then the workspace properties could be
> retrieved for the resulting VCRs and the one with the right property
> could be used for the check-out. Is there an alternative for this?

It makes no sense to checkout a VCR in some random workspace.  A workspace
is owned by a particular individual (or perhaps team) that wants to see a
consistent configuration (i.e. the configuration defined by the VCR's in 
that
workspace).  When you checkout a VCR, you checkout the version of that VCR
that is in that configuration, and if you want some other version to 
appear in
that configuration, you perform an UPDATE to make that version appear in 
that
workspace.

Cheers,
Geoff