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

Re: Versioning TeleConf Agenda, 12/1/00 (Friday) 12-1pm EST

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Sat, 2 Dec 2000 08:22:58 -0500 (EST)
Message-Id: <200012021322.IAA08194@tantalum.atria.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT