Re: draft of CHECKOUT method
John Vasta (vasta@rational.com)
Wed, 13 Oct 1999 10:24:27 -0400
From: "John Vasta" <vasta@rational.com>
To: <ejw@ics.uci.edu>, <ietf-dav-versioning@w3.org>
Date: Wed, 13 Oct 1999 10:24:27 -0400
Message-ID: <001501bf1586$a7f4ea30$bf68f3ce@amaretto.atria.com>
In-Reply-To: <NDBBIKLAGLCOPGKGADOJIEIKCGAA.ejw@ics.uci.edu>
Subject: RE: draft of CHECKOUT method
> One thought I had on CHECKOUT today is that I think we want CHECKOUT to
> return a list of other working resources that are currently active and were
> also created by a checkout against the same parent. An authoring client
> would use this information to inform a user that they are about to enter a
> parallel development/authoring situation, and give them the option to not
> continue if they do not wish to merge.
This could be expensive to compute for some repositories; I would not like to
see it required of every CHECKOUT operation.
Also, just knowing about active working resources doesn't help; there could be
inactive (i.e. checked-in) revisions in activities which branched off the same
parent revision. So you would need to know about any merges pending in those
activities.
And it seems to me that clients will declare their intention to work in a
parallel development environment (by virtue of using activities in their
workspaces). Such clients would expect to deal with the consequences.
> While a client could query for this before performing the checkout, there's
> no guarantee someone else wouldn't sneak in a checkout between the query and
> the following checkout, thus making the query result out-of-date.
Couldn't the query be done after the checkout, to see whether theirs is the
only checkout? Or were you proposing that the checkout fail? Otherwise, it
seems as if a post-checkout query would do what you wish for the clients that
are interested, without making all clients pay the price.
John Vasta