Re: checkin-set

>> 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.donne@re.be

Received on Wednesday, 12 April 2006 19:21:57 UTC