[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: ra_replay: Uncovering a latent design failure

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 11 Jan 2013 14:23:21 -0500

On 01/11/2013 12:15 PM, C. Michael Pilato wrote:
> So. Looks like I'll be taking a little detour here to try to fix this in a
> compatibility-preserving way. Here's my plan:
>
> Server-side: Recognize which resource was hit with the request, looking for
> the (optional) path filter in the REPORT request body if the "me resource"
> or "default VCC" were used. Advertise the new support so clients can
> construct the best REPORTs possible.
>
> Client-side: If the server supports the correct constructs, drop the path
> filter into the REPORT body and issue the request against the "me resource"
> or "default VCC" (if non-httpv2). Otherwise, just keep on doing what we do
> today and wish for the best.

Actually, I think I'll take a slightly differently approach here. Rather
than have the client hit the "me resource" (which represents the whole
repository), I'll have it hit the revision resource associated with the
single revision that's being replayed.

   .../!svn/rev/REVNUM

That way, requests to replay revisions which don't exist will 404 (as we'd
expect), plus we won't have to marshal the revision number in the request
body -- just the filtering path. (In fact, in the future, we may decide to
allow multiple filtering paths here.)

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2013-01-11 20:23:55 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.