Re: Subversion support

[ Tim respectively sent privately because of the queries about the
  functionality of the server; however, it is an Open Source project, so I
  (thankfully) have no IP to protect and can respond publicly. Tim okay'd
  posting this back to the list ]

On Thu, Dec 21, 2000 at 01:34:47PM +0000, Tim_Ellison@uk.ibm.com wrote:
> Greg Stein wrote:
> 
> 24.xxx  Subversion 1.0 (http://subversion.tigris.org/)
> 
>    A. Subversion client
>       i. Required options:
>          a. RFC 2518, Class 1  (but not Class 2)
>       b. Core versioning (but not: VERSION-CONTROL, UNCHECKOUT, or
>          SET-TARGET)
> 
> So do you support unversioned resources at all? or do you use CHECKIN to
> bring them under version control?

There are no unversioned resources within a Subversion repository. However,
we *can* place that repository anywhere in the server's URL space, so it is
definitely possible that unversioned resources will exist on the *server*.

For example:

   http://www.lyra.org/index.html    -- unversioned
   http://www.lyra.org/svn/...       -- everything in here is versioned

Given that VERSION-CONTROL will be a simple no-op (based on Geoff's
comments), I will support that. If you try it outside of an SVN repository,
then Apache simply won't recognize the method and will return an error.

And it sounds like UNCHECKOUT and SET-TARGET left Core, so I'm okay there.

(I won't support UNCHECKOUT since it is part of the server-workspace option
 and SVN uses the client-workspace model; and SET-TARGET is now its own
 option; SVN won't support either of these options)

>       c. Client-Workspace option
>       d. Label option  (probably; not entirely sure because our "label"
>          may simply be a COPY)
>          [ this also presumes Label will be split from Client-WS ]
> 
> I don't understand.  How do you implement labels as a COPY?

SVN can do a copy-by-reference, so they're cheap as hell. I can label
something simply by doing:

  COPY http://www.lyra.org/svn/project
  Destination: http://www.lyra.org/svn/labels/1.0a1

Assuming nobody monkeys in the 1.0a1 tree, it will reflect the state of
"/svn/project" at the time of the COPY. Of course, we can also apply a
simple ACL to prevent that monkeying (but then again: we might want to apply
fixes to the alpha).

That said, I think we might do labels in the classic RCS/CVS sense simply
for the user-model aspect. That's why I'm tentative with labels. I think
we'd like to keep them as copies, but it can be a funny model for some
people.

"how do I see my labels?" "well, go over to that part of the tree" "oh, is
that 'labels' subtree part of the system?" "nah... we just picked that... it
is a policy choice" "WTF?!" :-)

>       e. Activity option
>       f. Version-History-Resource option
>       g. Version-Controlled-Collection option
>       h. Fork-Control option
>       i. Subversion-specific items: a custom report, DAV:version-name
>          must be an integer representing repository-global-change,
> 
> Note that the DAV:version-name is server chosen anyway so 'must be an
> integer' -> 'is an integer'

As I said to Geoff :-) ... the server does choose it, yes. But we're talking
about what the client expects here. And the client *requires* that
version-name to be an integer.

(and that creates a pretty hard dependency/expectation on the server)

>           atomic
>          CHECKIN of activities, DAV:prop supported within the DAV:checkin
>          element (to enable returning post-checkin information, such as
>          new version resource URLs), possibly other TBD items???
> 
> I'll need to think about how you can do that -- because if it is a working
> resource you are checking in the resource has gone after the CHECKIN, so
> what URL would you put in the propstat response?  Its easier for a VCR but
> I know you'll need it on working resources too.

The new version resource (resulting from the CHECKIN).

I think we're okay on this one, due to the activity-MERGE. (assuming nobody
has big problems with that one)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Friday, 22 December 2000 04:43:04 UTC