Re: Merge Example in <version-goals-01221999.htm>
jamsden@us.ibm.com
Sun, 24 Jan 1999 11:12:37 -0500
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256703.0059B21A.00@d54mta03.raleigh.ibm.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.