From: email@example.com To: firstname.lastname@example.org Message-ID: <85256703.0059B21A.email@example.com> Date: Sun, 24 Jan 1999 11:12:37 -0500 Subject: Re: Merge Example in <version-goals-01221999.htm> > This certainly suffices. What advise would you give on where to implement this policy so that it is the automatic behavior of the system whenever anyone checks out any versioned resource? Would it be enforced/facilitated by a special client? A special server? If in the server, does the protocol allow the server to fail Joe's checkout because he didn't specify a new activity for his work, just as it failed Jane's checkout for this reason? < Sean, The typical way to handle parallel development is to have the owner of a resource control the mainline activity and do most merging. In situations where there is no clear owner, or perhaps many different owners over the lifecycle of the resource, the mainline can be completely reserved by some CM administrator and given out through access control mechanisms in a controlled manner. The danger with these approaches is that they produce a lot of parallel activities that require merging, and may result in a greater potential for merge errors. An alternative is to be more proactive about who is doing what changes when, and plan activities to avoid parallel development on the same resources. These are issues that are beyond the protocol or its semantics though as different organizations will want to use the protocol to support many different policies. These behaviors could be implemented in a client application, or they could be handled by manual administration and/or development procedures.