Re: Subversion support

   From: Greg Stein <gstein@lyra.org>

   ...
   I'm reporting the status of the client files to the server as the *input*,
   and it returns information about what is out of date.
   ...

I'll mull this over for a bit to see if I can think of a form of this
report that is not wired into the Subversion implementation.  I will
probably have some questions, but it probably makes more sense to
pursue this thread on the subversion mailing list.


   > 	       DAV:version-name must be an integer representing
   > 	       repository-global-change,
   > 
   > DAV:version-name is server defined, so that can be whatever you want
   > it to be.

   On the server, yes. I put this under "required client options." The client
   *expects* this to be an integer.

OK, I get it.  That means that your client won't work unless it is an
integer?  Is this a release-1 style constraint that you would try to
relax (for interoperability) in a later release, or is that something
that is intrinsic to the design of your client?

   > I added atomic checkin of activities in the MERGE
   > request, so that's now part of the activity option.

   Hmm. I read the new draft. I'm unsure if the "MERGE <activity>"
   does the checkin now. It seems to imply that a merge of an activity
   will cause all checked-out resources to be checked in first, then
   the merge to the VCR is performed.  Is that the general sense?

Yes, that's it.  I'll try to update the section to make this clearer.

   Hmm. I see CHECKOUT isn't there either... off in the client/server
   workspace options. Quick question/point: what should a server
   return for a CHECKOUT against the wrong type of resource?
   e.g. should I return 409 (Conflict) if somebody does a CHECKOUT on
   a VCR? Is there a specific <DAV:error code> to return for this
   situation?

If the resource doesn't support CHECKOUT at all, then that would be a
405 (Method not Allowed).  If the resource in theory supports the
method but your server will never allow it, that's a 403 (Forbidden).
If there's something the user could do to the resource, that's a 409
(Conflict), and you could return (DAV:must-be-checked-in).

   It seems like a core server is awfully thin now. And does the
   DAV:version-tree report go into the "Version History Option" since it
   operates against a version history?
  
The DAV:version-tree report is part of core.  Every versioning
server must provide the concept of a version history (which is why
the concept appears in core versioning), but the only way of accessing
this information in core versioning is the DAV:version-tree REPORT.

Cheers,
Geoff

Received on Friday, 22 December 2000 16:51:01 UTC