Message-ID: <00f801be45a6$fa5ae0a0$cf4406d1@honey-bee> From: "Sankar Virdhagriswaran" <email@example.com> To: <firstname.lastname@example.org> Cc: <email@example.com> Date: Thu, 21 Jan 1999 20:01:17 -0500 Subject: Re: CHECKIN/CHECKOUT - Mutable resources and a call for consensus >For example, in systems that support parallel development, when activities >are merged, the system can generate the conflicts list, and can maintain >the list as they are resolved by the author. Having this capability is of >enormous importance because it helps make sure changes aren't lost. If >revisions are allowed to change, then an author cannot rely on the >conflicts list. New conflicts could be created at any time without any >record. Similarly, changing revisions of resources in a configuration used >to deploy a web application compromises the ability to re-create a >particular distribution. Hear, Hear. >Sure, changing a spelling mistake in a document >might not have any significant effect on the configuration, but what about >changing an assignment in a script that is part of an HTML page? Where does >it stop? Is this something you want to leave up to any author to decide? >Authoring web resources is much more than authoring static documents, and >the versioning requirements are much stricter. The question is, do document >management systems have the same semantics? Should they? Do they care about >parallel development and configurations? How many options do we expect >client applications to deal with? Are these issues we want to resolve in >the protocol, or are they client issues? > IMHO these are important issues that the versioning working group should deal with.