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.
Ben Collins-Sussman wrote:
>Karl Fogel <kfogel@newton.ch.collab.net> writes:
>
>
>
>>Ben Collins-Sussman <sussman@collab.net> writes:
>>
>>
>>>But we can't retroactively change released clients. mbk, we need to
>>>come up with a solution here. Perhaps a different, more compatible
>>>way to marshal the UUID from server to client. We can't release a
>>>0.19 server that chokes earlier clients. :-(
>>>
>>>
>>I'm not sure about "can't" (we can always warn people to upgrade
>>clients before servers, this being alpha and all). But it would sure
>>be nice to avoid it!
>>
>>MBK, one solution might be to add a header to the client requests,
>>something like
>>
>> X-repository-uuid-accepted
>>
>>...or whatever. The server would never send UUIDs unless this header
>>were present. But is this veering dangerously close to a full
>>features exchange, implying that we should come up with a more general
>>mechanism for that?
>>
>>
>
>Or even easier: have a UUID-aware server add an X-SVN-Repository-UUID:
>header to its responses. An ignorant client will just ignore the
>header. A new client will explicitly look for the header.
>
>Note that this means the UUID is global to the server repsonse, not
>attached to individual files. That's fine for the moment. We can
>teach 0.19 to not choke on per-file UUID properties, but we won't send
>them just yet. In the future, they can be used to 'override' the
>global value, much like the way our entries file works.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 4 20:41:13 2003