Re: Change sets and activities

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 UTC