checkin-set

Hi,

If activities and workspaces are used together to implement
branches,
each branch could be checked out if there is a workspace,
which has a
VCR, that is linked to the first version of that branch.

If I now want to do a check out in a branch I need to locate
the
correct VCR. Since the branches are 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.

How can I find the correct VCR given a version and knowing
in which
workspace I want to do it? 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. 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?

Regards,

Werner.
-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donnere.be

>> 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.

I meant a workspace with a VCR that was created with the
first version
of the 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.

I think this is the clue. If the current activity of a
workspace is
changed, can this affect the checked-in version of a VCR? Is
the system
allowed to set it to the most recent version within the
activity if
such a version exists?

> 
>> 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"?

Yes.

> 
>> 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.

Do I understand it correctly then that if a user wants to
check out on a
branch/activity within a version history he has to
"import" the last version
in that activity by making sure there is a VCR in his
workspace that has
its checked-in version set to it? Possibly the user has to
create a VCR first
in his workspace using that version.

If that is true, and assuming collections are supported, the
user has the
flexibility to create his own "directory tree"
in his workspace with all the
items he is working on. On the other hand he always has to
do this "import"
action and manage this "directory tree". Would
it be allowed to generate
VCRs automatically when a workspace is created? For example,
VCR /a/b/c would
lead to /ws/myws/a/b/c.

> 
> Cheers,
> Geoff

Regards,

Werner.
-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donnere.be

Thank you very much.

Regards,

Werner.
-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donnere.be