RE: Eclipsed resources...

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

   The deltav draft (section 14.1.1) says that a non
   version-controlled resource can "eclipse" a version-controlled
   resource.  When the non version-controlled resource is deleted or
   moved the version-controlled member is exposed.

   I have a few questions/issues regarding this concept: 

   1) What happens if a VERSION-CONTROL request is issued on the non
      version-controlled member that is eclipsing the
      version-controlled resource?

The VERSION-CONTROL request would fail because there already is a
version-controlled binding with that name.

   2) BASELINE-CONTROL can be issued with a baseline URL in the
      request body (in order to populate the collection), if there is
      a non version-controlled resource at the destination whose
      binding name clashes with the name of a member in the baseline
      does eclipsing occur?  It seems like the same scenario but
      eclipsing is not defined here.

If the server supports versioned collections, it is a regular eclipse.
If the server does not, then it is server defined, but for consistency,
a baselining server should demonstrate eclipsing behavior, even if
it does not support versioned-collections.

   3) Why was this defined this way around? Surely the
      version-controlled member should take precedence over the non
      version-controlled resource.

Moving the non-version-controlled members out of the way to expose
the version-controlled members is always possible, while moving a
version-controlled member out of the way would require checking out
the version-controlled collection.

   4) Why was this behaviour defined instead of just failing the
      UPDATE or MERGE request.  This eclipsing behaviour seems odd and
      it may confuse end users to have their resources masked by some
      other resource.

In client workspace implementations, the non-version-controlled resources
are commonly local resources on the client, with only version-controlled
resources being stored on the server.  This means that a client-workspace
server would not know when an UPDATE or MERGE would cause a
version-controlled
resource to be "eclipsed" by some local resource on the client.
The eclipsing functionality provides more consistent behavior for a client
designed to work against both client-workspace and server-workspace
implementations.  In particular, the JSR-147 effort will take advantage of
this consistent behavior to define a single client library that unifies
interaction with client-workspace and server-workspace servers.

   Does anyone in the group have any good material explaining the
   "hows and whys" of eclipsed versions? How did it get into the spec
   in the first place, was there use cases etc?

It was pretty much just the preceding paragraph.

Cheers,
Geoff

Received on Wednesday, 24 October 2001 00:05:44 UTC