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

RE: Workspaces and File&Folder Hierarchy

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 13 Dec 2001 02:28:56 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B1052AD4A6@SUS-MA1IT01>
To: "Ietf-Dav-Versioning (E-mail)" <ietf-dav-versioning@w3.org>
   From: Kirmse, Daniel [mailto:daniel.kirmse@sap.com]

   But it is still possible to have a version tree (not a single line of
   descent of versions for the only VCR in the workspace)???

Remember that a workspace contains version-controlled resources,
not versions or version histories.  So I'm not sure what you mean
by "having a version tree" in the workspace.

   Well it would
   produce a ambiguity, wouldn't it? And then there is no unambigious merge
   baselining can take place. 

Remember that each version-controlled resource refers to exactly one
version in its dav:checked-in or dav:checked-out property.  So there
is no ambiguity about what version is associated with a given
version-controlled resource.

   So I would rather understand it that way, that
   you should have a <checkin-fork><forbidden> behavior for the versions.
   that it would be possible that more than one developer checks out a given
   version but at check in time they would be forced to do an explicit merge
   and the single line of descent and the unabiguity would be kept.

Perhaps you are thinking that a version-controlled resource always
refers to the "latest" version in a version history?  This is definitely
not the case.  It refers to the last version checked-in to that working
resource, or to an arbitrary version (of that version history)
specified in an UPDATE request.

So there is no ambiguity if there are forks and multiple lines of 

Received on Thursday, 13 December 2001 02:29:35 UTC

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