- From: Greg Stein <gstein@lyra.org>
- Date: Sat, 2 Dec 2000 06:41:47 -0800
- To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
- Cc: ietf-dav-versioning@w3.org
On Sat, Dec 02, 2000 at 08:22:58AM -0500, Geoffrey M. Clemm wrote:
>...
> I agree that supporting change sets is essential, but why does it matter
> whether or not (from the protocol perspective) that the change set be
> created atomically?
See below.
> I see no way to do a change set if the resources must be checked in
> individually.
>
> When you CHECKIN the first member of an activity, the version number
> can be assigned (to the activity). Subsequent CHECKIN's against that
> activity get the same version number.
Nope. If you get a conflict partway through, then the "assigned number" is
incorrect. The number can only be assigned once the full change set has been
comitted (they are sequential).
Consider: Joe begins the CHECKIN on the resources and the server gave him
version number 7. Nancy begins her checkin and the server gives her 8.
Oops... Joe's checkin has failed. Now what?
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.
I don't see it working well at all.
> Not to mention the transactional problems with that. For
> example, if checkout-fork is true ("allow multiple checkouts"), but
> checkin-fork is false ("can't check in if the checked out version is not the
> latest"), then I need to cancel the *entire* checkin if *any* of the
> checkins would create a fork.
>
> When there is a problem with checking in some element of a change set,
> users doesn't want you to throw away their changes ...
We haven't. All the changes are still residing on the user's machine.
> they are going
> to keep fixing things (i.e. merging, whatever) until the problem
> element can be checked in. Why not allow intermediate states of that
> change set to be manifested on the server?
Because the whole shebang is transacted. You either have a change set, or
you don't. You don't get a version number until the change set is committed.
There is no way to do a partial change set.
> In particular, if you've
> got a huge change set, and you've got a "checkin-fork forbidden" server,
> you may never get your change set accepted because by the time you've
> done a merge for some work, someone else has created a descendent of
> another of your changes, and you get another checkin conflict.
True, but that isn't your problem.
> If you
> allow intermediate states to be stored on the server, you can at least
> get most of your changes in (so the other guy has to do the merge :-).
Again: can't do. The whole change set goes in, or it doesn't.
The intermediate states *do* get stored into the working resources (but they
are not and *cannot* be visible to others). When everything is ready, a
commit is performed. That commit corresponds to checking in the activity.
> Note: I'm happy to have the protocol support activity checkin, so
> I just want to make sure I understand the motivation (in case I am
> called upon to defend it's addition to the protocol :-).
Sure.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Saturday, 2 December 2000 09:43:09 UTC