- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 13 Dec 2001 02:28:56 -0500
- 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 or 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. With 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 descent. Cheers, Geoff
Received on Thursday, 13 December 2001 02:29:35 UTC