checkin-set

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

checkin-set

Werner Donné

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: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: checkin-set

Geoffrey M Clemm

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
Reply | Threaded
Open this post in threaded view
|

Re: checkin-set

Werner Donné

>> 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: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: checkin-set

Geoffrey M Clemm

Werner Donné <[hidden email]> wrote on 04/12/2006 03:21:44 PM:

> >> 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.
> >
> > Not sure what you mean by "linking the VCR to the first version of that
> > branch".

> I meant a workspace with a VCR that was created with the first version
> of the branch/activity.


In general, there would not be (and would not need to be) such a workspace.

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


You can do this, but you use the MERGE method (see section 13.12 in RFC-3253).
Changing the DAV:current-activity of the workspace has no effect
on the checked-in version of any VCR in the 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.


Yes.

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


He could do that, but it would be more useful for the collections to be under
baseline control, so that the user UPDATEs his workspace with a baseline,
which pulls in a consistent configuration of all of these items and of the
collections that contain them (so that the namespace of the files items is
under version control as well).

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


Yes, that is what baselines and BASELINE-CONTROL of collections provides.

Cheers,
Geoff


Reply | Threaded
Open this post in threaded view
|

Re: checkin-set

Werner Donné

Thank you very much.

Regards,

Werner.
--
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]