W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2001

RE: Parallel Development

From: Tim Ellison <Tim_Ellison@uk.ibm.com>
Date: Fri, 14 Dec 2001 12:08:32 +0000
To: "Ietf-Dav-Versioning (E-mail)" <ietf-dav-versioning@w3.org>
Message-ID: <OF3CD13BC2.0377EED8-ON80256B22.00429EA1@portsmouth.uk.ibm.com>
Right on!
Your description is correct.


"Kirmse, Daniel" <daniel.kirmse@sap.com>
Sent by: ietf-dav-versioning-request@w3.org
2001-12-14 11:39 AM

        To:     "Ietf-Dav-Versioning (E-mail)" <ietf-dav-versioning@w3.org>
        Subject:        RE: Parallel Development



i've got this (at least I think so ;o) ). Now we advance a step further:

Suppose this situation:

    +--------+               +-------+               +--------+
    |  VCR1  |               |  VH1  |               |  VCR2  |
    +--------+               +-------+               +--------+
    | CIN V2-+------+        |  V1   |      +--------+-CIN V2 |
    +--------+      |        |   |   |      |        +--------+
                    +--------+->V2 <-+------+

The checked-in (CIN) versions of VCR1 and VCR2 are located in the very 
VH and they are even the same version.

Now same problem to checkouts on the same version via the VCR's. To be
precise there is a checkout on VCR1 with DAV:apply-to-version flag which
creates WR1 with DAV:auto-update = VCR1. And there is a checkout on VCR2
with DAV:apply-to-version flag which creates WR2 with DAV:auto-update =
VCR2. Performing a checkin on both WR's would cause no failed checkin but
produces this situation:

    +--------+               +-------+               +--------+
    |  VCR1  |               |  VH1  |               |  VCR2  |
    +--------+               +-------+               +--------+
    | CIN V3-+------+        |  V1   |      +--------+-CIN V4 |
    +--------+      |        |   |   |      |        +--------+
                    |        |  V2   |      |
                    |        |  / \  |      |
                    +--------+>V3 V4<+------+

Am I right with this? Please let me be! Otherwise I should give up trying 
understand this (at least for this week) ! ;o)

P.S.: Obviously there MUST NOT be any DAV:checkin-fork forbidden property 

>-----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.
>   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
>   contains a new version V2 that is a descendant of V1. In my
>   the checked-in property of the VCR is set to V2 during this checkin.
>   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.
Received on Friday, 14 December 2001 07:15:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC