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

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

From: Greg Stein <gstein@lyra.org>
Date: Fri, 8 Dec 2000 00:53:33 -0800
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
Cc: ietf-dav-versioning@w3.org
Message-ID: <20001208005333.M27505@lyra.org>
On Tue, Dec 05, 2000 at 10:23:26AM -0500, Geoffrey M. Clemm wrote:
>    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?

Because the repository does not provide for partial checkin of change sets.

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

Let's say that Joe has foo.c checked out and it has a working resource as
part of the activity -- due for checkin. That checkin will be v7. The server
assigns v7 to Joe and waits for the individual checkins to arrive.

Jane comes along and wants to check in an update to foo.c also. She had v6
and the server goes "you can't check in your changes. you can only check in
relative to the latest (v7)." But Jane can't get the latest.

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

I don't care what Nancy gets. I care that both v7 and v8 exist in the

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

Nancy doesn't. The repository does.

[ you are otherwise correct on the non-sequential numbers for deltas on a
  particular file. the file could be the same for v1..10 and then change in
  version v11. ]

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

I mean rolling back the entire checkin/activity. As I mentioned, we cannot
have partial checkins in the repository.

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

The point is that all the checkins in an activity must succeed or fail in
total. So they are /not/ independent. And since they aren't independent,
HTTP's stateless nature creates problems if you attempt to check them 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.
> I understand that is the way you're implementing it, but I'm wondering
> why you implemented it that way.

Because that is how we implemented it. That is enough for this forum. Unless
you are going to try and say that a transacted change is not in scope for
the DeltaV protocol.


Greg Stein, http://www.lyra.org/
Received on Friday, 8 December 2000 03:52:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC