Re: mod_dav_svn backward compatibility broken?

mark benedetto king <mbk@boredom.org> writes:
> 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.

Does it really preclude that? What if the header UUID is treated as
the default, but an individual resource could override it, someday in
the future.

> 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.

We'd wait to upgrade, if it were going to be incompatible.

> 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).

This isn't really an option for the present problem, because it
doesn't help old clients (0.18.0 and 0.18.1). We can't go back and
change *their* code :-).

> 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.

Me too.

---------------------------------------------------------------------
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:49:14 2003