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

Re: Change sets and activities

From: Greg Stein <gstein@lyra.org>
Date: Wed, 13 Dec 2000 17:12:52 -0800
To: Jim Amsden <jamsden@us.ibm.com>
Cc: ietf-dav-versioning@w3.org
Message-ID: <20001213171252.L8951@lyra.org>
On Tue, Dec 12, 2000 at 10:13:22PM -0500, Jim Amsden wrote:
> <greg>You've got all kinds of race conditions and stuff going in there to
> try and
> deal with the problem. Sure, the server knows all of the files that Joe is
> going to checkin (through examination of the activity), but it can't do
> anything about it until all the files are checked in. Does it say "well,
> there is a v7 for this file, but I can't give it to you right now." What if
> Joe never comes back? Nancy should have got v7 in that case. Oh, and what
> happens with rollback for Joe's failed checkin? Or is that first resource
> supposed to fail on checkin because some *other* resource in the activity
> is
> going to fail in the future.</greg>
> 
> I don't think we ever considered DAV:version-names to play this role. We
> considered them a way to distinguish revisions that is set by the server
> for display purposes, they can't be used to access the version. WebDAV
> defines the change set to be the latest versions in an activity. It doesn't
> say that all the changes were created at the same time. This moves the
> validation of the change set to after checkin, not before. I understand
> this might not be ideal.

Those were names I was using to refer to the internal mechanics and
implementation. The repository transacts the changes, and assigns a number
at commit time for the transaction.

It is impossible to have a partial commit, and assign a number. It must all
be there, or none of it will be there. If Joe is working on his commit, and
Nancy zooms in with a quick commit, then she'll get v7, and Joe's commit
will be v8.

This transacted commit behavior is to avoid the race conditions and
non-determinism mentioned above. Individual working resources cannot be
checked in (via CHECKIN) because the whole set must go in as a group.
Therefore, the activity CHECKIN as the signal for the group.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Wednesday, 13 December 2000 20:09:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT