W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2002

RE: Parallel Development

From: Kirmse, Daniel <daniel.kirmse@sap.com>
Date: Thu, 24 Jan 2002 16:51:08 +0100
Message-ID: <59357A260E15D311B5A60008C75D3530068B4784@dbwdfx13.wdf.sap-ag.de>
To: "Ietf-Dav-Versioning (E-mail)" <ietf-dav-versioning@w3.org>
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.
>   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 Thursday, 24 January 2002 10:51:56 UTC

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