Various comments...

Hi,

I am not sure what scope we have for change to the specification (now that
it's completed last call),
but here are various issues/observations on draft 18:

Section 11.2, the MERGE method does not have pre or post conditions that
define what should
happen if the DAV:source and the target URL point to the same version of a
resource.  I am 
assuming that the MERGE would return a success but basically be a no-op.

Section 11.2 the DAV:descendent-version postcondition is missing a full stop
(period) at the end
of the sentence.

Section 11.3 should the DAV:ignored-preview set include resources that are
the same in both
the target and source (do not require merging) as well as resources that are
not present in
the target.  It seems like identifying resources which are ignored because
they are identical
would be a useful thing for this report to return.

Section 11.3.1 in this example it would be good to show a example
DAV:ignored-preview element
and to show a element which has multiple resources, eg multiple
conflict-previews (more than one
resource in the two workspaces that conflicts).  The current example is very
simple and MERGE
is quite complex.

Reading section 11 it implies that when DAV:source is a workspace (or
collection) and the
target URL is also a workspace (or collection) if a VCR is found in the
source collection
but not in the target it is ignored and not added, this seems odd.  Why is
this? Surely the 
file should be added to the target collection.

The VERSION-CONTROL method can be used to create multiple VCRs pointing to
the same
version history (provided they are not in a workspace).  How would this
affect MERGE?
Imagine a collection containing multiple VCRs (which DAV:checked-in pointing
to potentially 
different versions) of the same VHR.  What would happen when a MERGE request
was carried
out on the collection? Which VCR would be the target?

Finally, section 10.2 defines a "Collection Version Resource" and this says
that a collection
version captures bindings to VCRs.  But later in section 14 a version
controlled collection
is defined as having bindings to version histories (VHRs).  I think section
10 is misleading
and section 14 is correct.

Some of the issues regarding merging I had to explain to a group of MERANT
staff so
I drew some Powerpoint slides to help.  Find these slides attached to the
e-mail, they
may help explain the scenarios I am talking about.

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