RE: Parallel Development

   From: Kirmse, Daniel [mailto:daniel.kirmse@sap.com]

   Suppose a development environment where the development codeline is
   kept in a workspace. Within this Workspace there is a VCR /DEV/a.c
   the checked-in property points to version V1. Now there is a
   checkout of the checked-in version of /DEV/a.c into a
   working-resource WR1.

I will assume this CHECKOUT was done by applying a CHECKOUT to
/DEV/a.c, with the DAV:apply-to-version flag.  (As Tim points out,
this has slightly different behavior from explicitly applying the
CHECKOUT to a version resource).

   In my understanding of DeltaV the checked-in property of the VCR is
   not changed by this action.

Correct.

   Now another checkout of the checked-in version into a
   working-resource WR2 is done (i.e. two developer working parallel
   on the same source). Rigth so far?

Yes.  Again, I will assume that this was a CHECKOUT of /DEV/a.c with
the DAV:apply-to-version flag.

   Now WR1 is checked in. WR1 disappears the version history (VH) of
/DEV/a.c
   contains a new version V2 that is a descendant of V1. In my understanding
   the checked-in property of the VCR is set to V2 during this checkin.
Still
   right?

Yes, if WR1 resulted from checking out /DEV/a.c with the
DAV:apply-to-version flag.

   Now WR2 is checked in. Checkin fork is forbidden. Because there is a
   descendent to V1 allready and the checkin fork is forbidden.

Actually, there is no need to have Checkin-fork to be forbidden
(although it doesn't hurt to have it set to be that).  The
DAV:no-overwrite-by-auto-update postcondition of CHECKIN will
force the CHECKIN to fail.

   So a merge must be forced (how?).

I'm not sure if you are asking "how is it forced" or "how do you do
the merge"?  It is forced, because every time you try to CHECKIN, it
will fail with the postcondition identified above.  The client does
the merge by downloading the current content of /DEV/a.c, merging that
into the content of WR2, and then adding the DAV:checked-in version to
the DAV:predecessor set of WR2.  Then the CHECKIN will succeed,
because the DAV:overwrite-by-auto-update condition is no longer true.

   After that done the checked-in property of the VCR points
   to the merged version of V2 and the checked in version of WR2. Right?

Actually, the checked-in property of the VCR points to the version
that resulted from checking in WR2, where the content of WR2 is the
merge of the previous state of WR2 with the state of the checked-in
version of /DEV/a.c.


   Background:
   I have a development codeline. A file to edit is a VCR. I want the
   possibility of two (or more) developers working parallel with this
   file. But I want them to do a merge of their work at the second
   checkin (the checkin of the first developer causes no
   problems). And I want the VCR point to the most current checked-in
   version of its VH automatically. Is this achieveable? I think it
   must be, since this is what can be done using Perforce.

Yes, it is.  Just have the developers client apply CHECKOUT with
DAV:apply-to-version to a version-controlled resource.

Cheers,
Geoff

Received on Thursday, 13 December 2001 23:56:42 UTC