Using activities for branching

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

Using activities for branching

Werner Donné

Hi,

I have trouble understanding how activities can be used effectively
for branching purposes. When one makes branches in a version history
this usually leads to a tree with different lines of descent.

As far as I see it is not possible to have work going on in different
branches at the same time, because in a version history there can only
be one checked-out version, which stems from the fact that a VCR has
at most one checked-out version. In other words, the branches are not
independent. That is not what I am used to with version systems.

Workspaces are of no help here, because you would have to introduce
a new VCR with an independent version history. There is no permanent
link between that version history and the one the workspace was created
from. With workspaces one can't "grow" branches on an existing version
history. Once a workspace is gone its version history is gone as
well.

Clearly, it should be possible to work in parallel and maintain the
history of all this parallel work. With workspaces you have parallel
work without a parallel history, whereas with activities you can have
a parallel history, but which can't be created in parallel.

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: Using activities for branching

Geoffrey M Clemm

Werner wrote on 03/24/2006 12:49:10 PM:
>
> I have trouble understanding how activities can be used effectively
> for branching purposes. When one makes branches in a version history
> this usually leads to a tree with different lines of descent.


Yes.

> As far as I see it is not possible to have work going on in different
> branches at the same time, because in a version history there can only
> be one checked-out version, which stems from the fact that a VCR has
> at most one checked-out version.


There are an arbitrary number of VCR's for a given version history
(at most one per workspace though), so there can be an arbitrary number
of concurrent checkouts from a single version history (or a single
version, for that matter).

> Workspaces are of no help here, because you would have to introduce
> a new VCR with an independent version history.  There is no permanent
> link between that version history and the one the workspace was created
> from.


You can use the VERSION-CONTROL method with a version as an argument
to create a VCR for an existing version history.  Also, you can use the
BASELINE-CONTROL method with an existing baseline, to create a whole bunch
of VCR's for a whole bunch of existing version histories.

> With workspaces one can't "grow" branches on an existing version
> history. Once a workspace is gone its version history is gone as
> well.


Deleting a workspace has no effect on any version or on any version
history; in particular, deleting a workspace does not delete any versions
or version histories.

Cheers,

Geoff
Reply | Threaded
Open this post in threaded view
|

Re: Using activities for branching

Werner Donné

Thank you again Geoff.

Regards,

Werner.

Geoffrey M Clemm wrote:

>
> Werner wrote on 03/24/2006 12:49:10 PM:
>>
>> I have trouble understanding how activities can be used effectively
>> for branching purposes. When one makes branches in a version history
>> this usually leads to a tree with different lines of descent.
>
> Yes.
>
>> As far as I see it is not possible to have work going on in different
>> branches at the same time, because in a version history there can only
>> be one checked-out version, which stems from the fact that a VCR has
>> at most one checked-out version.
>
> There are an arbitrary number of VCR's for a given version history
> (at most one per workspace though), so there can be an arbitrary number
> of concurrent checkouts from a single version history (or a single
> version, for that matter).
>
>> Workspaces are of no help here, because you would have to introduce
>> a new VCR with an independent version history.  There is no permanent
>> link between that version history and the one the workspace was created
>> from.
>
> You can use the VERSION-CONTROL method with a version as an argument
> to create a VCR for an existing version history.  Also, you can use the
> BASELINE-CONTROL method with an existing baseline, to create a whole bunch
> of VCR's for a whole bunch of existing version histories.
>
>> With workspaces one can't "grow" branches on an existing version
>> history. Once a workspace is gone its version history is gone as
>> well.
>
> Deleting a workspace has no effect on any version or on any version
> history; in particular, deleting a workspace does not delete any versions
> or version histories.
>
> Cheers,
> Geoff

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