Re: CHECKOUT of a baseline

On Thu, Jan 04, 2001 at 11:49:27PM -0500, Geoffrey M. Clemm wrote:
> 
> This needs to be fixed up slightly.
> 
>    From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
> 
>    ... specify the semantics of MERGE that the order of operations
>    when merging an activity are:
> 
>    1 - check-in working resources
>    2 - merge versions into merge targets
>    3 - check-in baselines
>    4 - merge baselines into merge targets
> 
> In step 3 (which should say "check in working baselines"), a working
> baseline does not have any particular baseline-controlled collection
> that it is associated with (only baseline selectors have that
> association), so it does not know which collection to scan for
> checked-in versions.

oooh... I see how you defined it. Interesting. I was thinking in terms of
"put the merge versions into the baseline," while you're keeping the same
"scan the VCRs" behavior. Nice.

And yes, it creates the complication you mention. But... :-)

> So we have to modify step 3 to say:
> 
> 3 - check in working baselines, using the baseline-controlled collection
> of the merge target of that working baseline.

Ah! Sneaky :-)

> Now I think we're OK.  (Assuming it's OK with Greg :-).

Totally okay with me. That models what I'm after.

Basically, I have a repository behavior already specified by Subversion
(which it is going to do no matter what we send over the wire). At this
point, I'm just trying to find the right mappings within DeltaV that
"marshal" that behavior. Where the holes are, I speak up, but also tempered
against keeping it general rather than SVN-specific.

With the above, I have an atomic commit of changes, creation of a new
baseline, and updating of the VCRs. I can't think how it could be better
than that! :-)

Thx,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Friday, 5 January 2001 05:10:18 UTC