Re[3]: More Check-out/in Branch Semantics

Bradley_Sergeant@intersolv.com
Tue, 20 Oct 1998 13:47:18 -0400 

From: Bradley_Sergeant@intersolv.com
Date: Tue, 20 Oct 1998 13:47:18 -0400
Message-ID: <001D0172.@intersolv.com>
To: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>,
Cc: ABabich@filenet.com, ietf-dav-versioning@w3.org
Subject: Re[3]: More Check-out/in Branch Semantics

     David said:
     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.
     
I agree that policy should be enforced by the server whenever posible and 
that the protocol should be designed with this in mind.

     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.
     
I see your point.  However, it was not my intention that the client be made 
to remember either of the branches.  The assumption I was making was that 
the client would decide at checkin if the branch was still desired, or if a 
merge was desired.  The branches involved can be derived from the state of 
the Vgraph and who owns which revisions.

Now if you want the CHECKOUT options to completely drive the behavior (at 
least the default behavior) of CHECKIN, then I can see you need more than 
just ForceBranch.

So now I see Geoff's original point.  If you use -reserve and can also 
designate a branch name indicating a branch other than the original branch, 
this serves the same purpose as -ForceBranch.

If we can also allow a new branch name, or some how indicate that a new 
branch is to be created (without even specifying a branch name), I think 
that solves all my original issues.

     --Sarge