Re: Etag-on-write, draft -04

On 12/2/06, Roy T. Fielding <fielding@gbiv.com> wrote:
> Actually, the Subversion client wouldn't know the contents anyway,
> since only the server knows the variable replacement contents even
> for something as simple as ID.  That is why etag should not be sent
> in that case, and the result works with any client. Even if the
> Subversion client thought it knew what the transformation would be,
> and what the Id value should be, it still wouldn't know if any other
> transformations might have occurred and thus would have to do a GET
> (or receive some other form of notification that would tell it how to
> transform its current representation to the current form).  A far more
> useful extension would be to define a new 2xx response to PUT that
> includes both the new metadata and a patch that would allow the
> client to implement a matching transformation on its own copy.
>
> OTOH, it would also be more sensible for the Subversion client to strip
> the contents within $Id$ itself, before the PUT, and thus both client
> and server would have the same content and a strong etag could be
> returned.  In other words, the client uses its knowledge of the resource
> definition to remove the unnecessary bits at the application layer
> above the HTTP processing, thus making the HTTP interaction more
> efficient.
>
> I have no idea what the current Subversion client does in that
> situation,
> so this is all hypothetical.

FWIW, Subversion does the keyword translation locally on the client
side (in libsvn_wc).  In other words, it follows the second
definition.  This is why if you do a HTTP GET, you don't see the
keywords expanded.  Only the Subversion client has enough knowledge to
do the translations - the client must untranslate the keywords before
sending it up to the server.

HTH.  -- justin

Received on Monday, 4 December 2006 09:48:17 UTC