Activity CHECKIN (was: Versioning TeleConf Agenda ...)

Some more questions just to make sure I understand the motivation
for activity CHECKIN.

   From: Greg Stein <gstein@lyra.org>

   On Sat, Dec 02, 2000 at 08:22:58AM -0500, Geoffrey M. Clemm wrote:

   > 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?

Why can't Joe's subsequent checkin's (against his #7 activity) be marked
as being part of version #7, i.e. what harm would it do to have the
partial change set #7 be completed at a future time?

   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."

Sounds reasonable.  Where would this cause a problem?

   What if
   Joe never comes back? Nancy should have got v7 in that case.

Why does Nancy care whether she gets the string "v7" or the string
"v8" to identify her change set?  If you're going to support branching,
you're going to have people getting non-sequential numbers anyway
(i.e. I'm based on version v7 but my next version I create will be
v11 because v8, v9, and v10 have been created on another branch).
And even if you're not supporting branching, why would Nancy care?

   Oh, and what
   happens with rollback for Joe's failed checkin?

What are you rolling back?  The checkin's that succeeded have created new
versions (which stay) and the checkin's that failed still are checked-out
resources.  Or do you mean, if you decide just to cancel the whole activity?
Just leave it "uncompleted" (you often end up wanting to look at partial
work like this), or delete those versions if you want to recover space.

   Or is that first resource
   supposed to fail on checkin because some *other* resource in the activity is
   going to fail in the future.

If each checkin can succeed or fail independently, there's no need
to have the checkin of one resource depend on the success or failure
of the checkin of another resource.  

   > 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.

I understand that is the way you're implementing it, but I'm wondering
why you implemented it that way.

And as before:

   > 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 :-).

Cheers,
Geoff

Received on Tuesday, 5 December 2000 10:24:09 UTC