RE: Parallel Development

The version that needs to be added to the predecessor-set
(preferably after merging its content to the working resource)
is the version identified by the DAV:checked-in property of
the VCR.

Cheers,
Geoff

-----Original Message-----
From: Kirmse, Daniel [mailto:daniel.kirmse@sap.com]
Sent: Thursday, January 24, 2002 10:51 AM
To: Ietf-Dav-Versioning (E-mail)
Subject: RE: Parallel Development


Is there a DeltaV defined response body for a checkin failing du to the
DAV:overwrite-by-auto-update postcondition? Or the other way around: How
does a server tell the client wich version has to be added to the
predecessor-set in order to successfully checkin the working resource?

>-----Original Message-----
>From: Clemm, Geoff [mailto:gclemm@rational.com]
>Sent: Freitag, 14. Dezember 2001 05:56
>To: Ietf-Dav-Versioning (E-mail)
>Subject: 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, 24 January 2002 14:40:02 UTC