Re[2]: More Check-out/in Branch Semantics
David G. Durand (dgd@cs.bu.edu)
Mon, 19 Oct 1998 17:20:33 -0400
Message-Id: <v03007805b2514ec2b5a5@[24.0.249.126]>
In-Reply-To: <001CDDF5.@intersolv.com>
Date: Mon, 19 Oct 1998 17:20:33 -0400
To: Bradley_Sergeant@intersolv.com,
"Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
From: "David G. Durand" <dgd@cs.bu.edu>
Cc: ABabich@filenet.com, ietf-dav-versioning@w3.org
Subject: Re[2]: More Check-out/in Branch Semantics
Brad's note got me started and then I ended up writing a kind of big thing
that harps on my general questions about client design and keeping policy
confined to servers.
At 10:48 AM -0400 10/19/98, Bradley_Sergeant@intersolv.com wrote:
> If you use unreserved and you want to checkin, the client must still
> specify whether he wants to merge or branch. This may be determined
> by a workspace setting, but this is no different from having the merge
> flag be a workspace setting. Seems to me the merge option simply
> documents choices that need to be made at CHECKIN whether you do and
> unreserve or a ReserveNewBranch option. What am I missing?
In Geoff's scenario, the checkout request tells the server to implement
logic creating a new branch, or to use the original branch at checkin time,
depending on whether other checkins have occurred since checkout. In
Geoffrey's scenario, the _server_ decides.
In the "forcebranch" scenario, the client must remember _both_ the main
branch name, and the name of the "reserved" branch, and whether the user's
intention is to check into the one or the other. They could be forcing a
branch because they _intend to create a new branch_ or because they want to
reserve a new branch in case they _don't_ check back into the mainline. The
server doesn't know this, so the client must remember it, or prompt the
user at every checkin.
In either case, the server might answer "merge is required to check into
the parent branch," so I don't see that forcebranch simplifies the protocol.
I can even imagine servers that would not create a new branch on an
unreserved checkin, but would simply add merge arcs. For example, if
revision 1 is checked out (unreserved); revision 2 gets created by a third
party; then when revision 3 is checked in, no branching may be required:
revision 3 can be recorded as a merge of revision 1 and revision 2. Of
course, the server must fail on the initial request to "simply" check in
revision 3.
The question is whether clients should be required to implement "unreserved
checkout" semantics if they are desired (and I think we agree that they are
needed), or whether that is something that _servers_ should implement, and
where clients can offer the option at their discretion.
I incline to thinking that the policy decisions should _all_ be made by
servers, and that clients should be offered all of the request options
required to work under reasonable server policies. It seems to me that
policy implementation in clients may make some policies unavailable to some
users even when using servers that support those policies. It also makes
clients more complex rather than simpler.
This does not _outlaw_ smarter, more policy sensitive clients. If one
_wants_ to enforce (or assumes) particular policies it need _not_ request
server options not wanted. It could even refuse to communicate with servers
that don't offer them guarantees (such as locking) that they wish enforced.
To drop down to a low level (protocol) for a minute, I think we want two
verbs:
checkout and checkin.
Each can request "locking" of the branch (reservation of a branch for checkin)
optional specification of which branch (change set) is desired
optional request that forking be prohibited/allowed.
server policies will determine what combinations of these are accepted and
when. We probably do need to say _if_ any guarantees should be made by a
server on accepting such an option: forking seems like the only one that
must generate a hard guarantee. Change-oriented systems can, for instance,
always answer yes to any lock request, if they want to, because they have
no system requirements for locking.
I haven't said what a nil (unspecified) branch ID might mean on either of
these requests. It could invoke some kind of default processing, or it
could signify that the server should create a branch. It may be that we
need to distinguish a user-specified branch, a request for a default
branch, or a request for the server to create a branch.
Also open is whether a special merge operation is required. An option flag
to checkin that changes its parameters seems clumsy to me, but instead of
an option, any checkin could specify a list of predecessor nodes (so that
any checkin could be a merge), then it seems more coherent than some kind
of option-setting interface.
I'm not an expert on branching models, but it seems to me that we should be
leaving policy to servers (which is where it currently seems to reside
anyway), and concentrate on allowing clients the ability to _request_ from
a server any options that make sense under any reasonable policy, whenever
it performs an operation. The server is always free to deny any such
request, as well as to suggest another kind of request: e.g. we probably
will need errors like "merge required for sucessful checkin".
-- David
_________________________________________
David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
--------------------------------------------\ http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW \__________________________