W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

RE: How Clients find out if they can perform a checkout

From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 3 Aug 2001 15:55:49 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E2564@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
> From: John Hall [mailto:johnhall@evergo.net]

> > From: Clemm, Geoff
> > The fact that some other version has a checkout has no effect
> > on whether or not your checkout will create a fork that might 
> > require a merge.  That is determined solely from whether or 
> > not the version you are checking out already has a descendent 
> > or checkout.
> I don't think that is true.
> Say that the latest checked in version is #5.
> User A checks out version #2 using working resource, intending to
> create a new version and then UPDATE the VCR with the newly created
> version.

Note that if User A is using a linear-versioning server, he will not
be able to check in because that would create a branch.  He would
first have to merge his working resource with whatever is the latest
version before he could checkin.  If he is using a forking server,
he will have to decide at checkin time whether to just checkin
(and thereby overwriting whatever is currently there) or first
do a merge (and thereby not overwrite what is there).  In either
case, User A set up the merge scenario by checking out a non-tip

> User B looks at version #5.  Version #5 has no current descendents,
> so just looking at Version #5 User B is unaware that User A also has
> a checkout that could cause a merge / update problem. To prevent
> this in an independent way, the client would have to check all
> previous versions to make sure they were not checked out.

There is nothing User B can do to prevent the merge/update problem.
It was created when User A checked out a non-tip version.  If User A
checks out version 5, since it is a tip version, he is guaranteed
that he is not causing a merge/update problem.  The only way for a
server to prevent the merge/update problem is to not allow forking
on checkout.  In this case, User A would not have been allowed to
checkout version 2 in the first place.

> I can easily think of clients that would not want to check out version
> #5 if ANY other version were checked out.

The only reason I can imagine for this would be if you wanted to
serialize access to the resource.  But then you would just use
the locking protocol (i.e. LOCK the vcr before checking it out,
and UNLOCK'ing it after you checkin).

Received on Friday, 3 August 2001 15:46:55 UTC

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