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

Parallel Development

From: Kirmse, Daniel <daniel.kirmse@sap.com>
Date: Thu, 13 Dec 2001 12:28:39 +0100
Message-ID: <59357A260E15D311B5A60008C75D3530068B4727@dbwdfx13.wdf.sap-ag.de>
To: "Ietf-Dav-Versioning (E-mail)" <ietf-dav-versioning@w3.org>

its getting complicated! First of all many thanks to everyone anwsering my
questions so far! It helped me a lot.

So next question:

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. 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?
If not, is there a way in DeltaV to get done the behavior described below?

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

Now WR2 is checked in. Checkin fork is forbidden. Because there is a
descendent to V1 allready and the checkin fork is forbidden. So a merge must
be forced (how?). 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?

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

Received on Thursday, 13 December 2001 06:29:11 UTC

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