Re: mod_dav_svn backward compatibility broken?

On Tue, Mar 04, 2003 at 01:53:15PM -0800, Ben Collins-Sussman wrote:
> Branko ÄŒibej <brane@xbc.nu> writes:
>
> > Why can't we jiust marshal the uuid as a property that just happens to
> > be present on every versionable resource? That not only makes sense
> > semantically (since we should be storing the uuid in the entries file),
> > it also means that any DAV client will see it, but can ignore it.
>
> Um, yes, that's exactly what we're doing. If you use WebDAV to ask a
> resource for all its properties, you'll see the UUID, DAV props, and
> user-controlled props.

Right. I think what Brane was getting at is that it should have been
shipped as one of the user-controlled props (which obviously don't suffer
from backwards-compatibility issues). I don't see anything wrong with that,
but I did include it where I did because it is processed in much the same
way.

Proposed so far to resolve this have been:

1.) A custom request header

        X-I-Know-About-UUIDs: true

        This would be easy to add, I think, but it might be worth
        doing (2) instead.

2.) A capabilities header

        X-I-Know-About: UUIDs, svndiff2

        This would be only marginally more difficult than (1), but does
        it open a slippery slope? Personally, I like it more than something
        like "X-RA-DAV-Version: 2", so that clients need not be fully
        compliant.

3.) A custom *response* header

        X-Repository-UUID: 32e0795c-b79d-4482-a8e7-4bf008f4a25f

        This is probably how I would have done it in the first place, had
        it occurred to me, but it does preclude sending different UUIDs
        for different files.

4.) Use existing properties infrastructure.

        The only thing I don't like about this is that the other WC
        props are transmitted one way, why should this one be different?

I suppose there are also:

5.) Do nothing.

        It's alpha, we can break the protocol. However, if we upgrade
        the svn.collab.net server and prevent everyone from upgrading
        with svn up, that would probably be bad, if only in terms of
        the increased dev@ list volume.

6.) Do less than nothing (stop validating S:prop so thoroughly) (be
    liberal in what we accept).

        Has all the problems of (5), but solves some things Once and
        For All(tm).

I'm not married to any one of these proposals; I think they all have
merit. If I had to choose, I think (4) would get my vote.

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 4 21:17:02 2003