On Thu, Aug 4, 2011 at 16:04, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>...
> Yes; the problem is that some client-initiated requests do not
> canonicalize a node's identification to its created-path_at_created-rev,
> and consequently some[1] opportunities for caching are missed.
>
> <handwaving>I suppose that could be remedied --- eg, if the wc started
> caching those created-* coordinates.</handwaving>
Yup. That's what the dav_cache is for. We just avoid using it in HTTPv2 (today).
>
> Thanks for the explanation,
>
> Daniel
>
> [1] Not sure what fraction of opportunities that 'some' is.
Right. The version resource URL stored in the dav_cache only
represents the node in the working copy. If you need to fetch content
during a merge, or you do an 'svn cat', or a diff... or other similar
operations, then you probably do *not* want the version sitting in
your working copy.
Let's also note that a cache can/will fill up with path_at_latest
resources. If 'latest' doesn't change often (think smaller projects),
then you'll still get cache hits there. Projects (well, repositories)
with quickly increasing revisions (think svn.apache.org) will miss
opportunities to cache some of these alternate requests.
Finally, note that our intent is to switch to requesting content by
<path, SHA1> tuples in the future. Those will be *very* cacheable (the
SHA1 acts as the created-rev). So even if ra_serf didn't have the
happy accident of using the server-provided URL, we would be returning
to a cacheable form in 1.8.
Cheers,
-g
Received on 2011-08-04 22:17:28 CEST