Issue #2959 is a new sparse-directories issue that was revealed by the
resolution of issue #2842.
See the issue for details, but basically the client needs a way to
know whether or not the server groks depth; the client needs to know
this *before* it starts the update report. (Search for the string
"server_supports_depth()" in the IRC transcript in issue #2959.)
But we don't want to add a new network turnaround, of course :-).
For svn:// this should be easy, because there's already capabilities
negotiation. But for http://, I'm not sure where to do it. We don't
seem to reliably send OPTIONS to the client, and (for example) neither
svn_ra_serf__open() nor svn_ra_neon__open() even contact the server in
order to create their session objects. I did a wireshark capture of
an http:// checkout (see http://pastebin.ca/730351), and I don't see
any obvious place to insert a "groks depth" token.
Is there some place where the server's already sending stuff, where we
could insert "groks-depth" without adding a new turnaround? (Once
we've added it, its absence would mean we're dealing with a
non-depth-aware server, of course.)
I'm not too expert at the DAV layer; any ideas would be much
appreciated.
There's the "Server: Apache/2.2.4 (Unix) DAV/2 SVN/1.5.0" line. We
could examine the version number there... But aside from being a
horrible way to deduce capabilities, it's probably not the right place
anyway. That line is traditionally under the discretion of the admin,
and some admins choose to hide the exact version, for security
reasons.
If you want to take a step back and consider other ways to solve the
problem, here's a detailed explanation:
Longer explanation of the problem:
==================================
When a 1.5.x client runs 'svn up --depth=infinity' in a working copy
directory whose top-level ambient depth is (say) depth=empty, the
client reports the directory's revision (say, HEAD) to the server, but
then does *not* report that many of the entries are missing due to the
depth.
For a depth-aware server, this is okay, because once the server hears
that the directory is at depth=empty, it knows which entries are
missing, and it knows (because this is a depth upgrade) to send those
entries down.
But if server is <= 1.4.x, it just hears that the directory is at
HEAD, hears nothing about missing entries, and responds "Nothing to
update!"
One way to fix this is to have the client set start_empty==TRUE on
set_path() calls for directories. Then the older server would assume
the directory is missing everything except what the client explicitly
claims to have.
For ambient_depth==empty, it's probably okay to do start_empty==TRUE
unconditionally. But for 'files' and 'immediates', we wouldn't want
to do that unconditionally, because then *new* servers could send back
more items than the client actually needs. Sure, maybe we could work
out some intricate way of noticing (on the server side), that the
client has set both start_empty and depth, and figure out that the
client is just hedging its bets and that we can ignore the start_empty
setting in favor of depth... But I don't think that would be
maintainable in the long run. It would be much better for the client
to simply know in advance whether the server supports depth, and take
corrective measures only when the server does not.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 9 05:50:39 2007