RE: Clarification on definition of a configuration....

Hi,

It was the text in section 12 where it says "... that are not members of
another 
configuration" that leads to the confusion.

Lets imagine you have the structure in the e-mail below and you put
the build collection under baseline control by issuing a BASELINE-CONTROL
request.

Can you now issue another BASELINE-CONTROL request on build/src?

I guess not since the resulting configuration would contain members
of the configuration defined by the initial BASELINE-CONTROL request.
Also the pre-condition (DAV:version-controlled-configuration-must-not-exist)
would be triggered because build/src already has a version-controlled
configuration property.

BUT...I guess you could have done that in the reverse order...eg...

If I issue a BASELINE-CONTROL method on build/src first I would then be
able to later put the build collection itself under BASELINE-CONTROL.

Is that right?

Would the second baseline contain members from build and build/include
but no members from build/src? Because the second configuration can
not contain members from the first configuration?

Regards,
--
Peter Raymond - MERANT
Principal Architect (PVCS)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
mailto:Peter.Raymond@merant.com
WWW: http://www.merant.com



-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@rational.com]
Sent: 27 September 2001 14:00
To: ietf-dav-versioning@w3.org
Subject: RE: Clarification on definition of a configuration....



   From: Peter Raymond [mailto:Peter.Raymond@merant.com]

   The statement in section 12 says: 

      "A configuration is a set of resources that consists of a root
      collection and all members of that root collection that are not
      members of another configuration."

   So given the collection structure: 

	   build 
	     | 
	     +----- include 
	     | 
	     +----- src 
		     | 
		     +----- gui 

   You cannot have a configuration rooted at build and another
   configuration rooted at build/src.

What in the definition led you to this conclusion?  (This is a real
question, not a rhetorical question, because if something in the text
led you to this conclusion, it should be fixed).

The statement you quote above just says that the members of the
nested (e.g. /build/src) configuration are not also members of the 
parent (e.g. /build) configuration.

   But later in section 12 it says: 

      "the root collection of a configuration can have a member that 
       is the root collection of one of its components" 

   So you can have a configuration rooted at build and a component
   rooted at build/src.

   Is my understanding of this correct? 

Yes, your final conclusion (i.e. that nested configurations are
allowed) is correct.

Cheers,
Geoff