- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Sat, 2 Dec 2000 08:22:58 -0500 (EST)
- To: ietf-dav-versioning@w3.org
From: Greg Stein <gstein@lyra.org>
On Fri, Dec 01, 2000 at 03:10:51PM -0500, Geoffrey M. Clemm wrote:
> This just provides a shorthand for checking in all the checked out
> resources associated with that activity. It appears that the only
> benefit is in decreasing the number of round trips. If anyone
> believes there is a semantic benefit to this operation, please
> explain it to the list.
It is not about decreasing round trips... not a bit. It is about
establishing a change set. All of the changes get checked in as a single
unit and assigned a version number.
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?
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.
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 ... 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? 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. 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 :-).
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 Saturday, 2 December 2000 08:23:44 UTC