Vlad Georgescu <vgeorgescu@gmail.com> writes:
> So, just to make sure I understand, with this patch:
> - we always send depth
> - requested depth is never svn_depth_unknown
Oh, the requested depth *can* be svn_depth_unknown, and we need to
allow that to reach the server. If it is unknown, then the server
just uses the reported depths for the paths available (or defaults to
whatever, if an old client didn't report any depths, and didn't
request a recursion level either).
> And the plan is:
> - only send depth when wc depth != the depth requested by the user
The plan is to send requested depth whenever the user explicitly
requests one, and not otherwise (or, maybe, send svn_depth_unknown,
but either way it should mean the same thing). Does that sound sane?
> - on the server side, if the client didn't send a depth, set requested
> depth to svn_depth_unknown (but if we got recurse=false, set requested
> depth to svn_depth_files, to accommodate old clients)
Right.
> The patch itself looks good, just one minor comment below:
>
> [...]
>
> If we wanted to save a few lines of code, we could have accept_report
> take both a depth and a boolean recurse, and do the necessary
> conversions in one place.
I think that would be tricky, because right now the conditionals are
examining the 'depth_word' variable to determine whether or not to use
the value of 'recurse'. accept_report() doesn't have access to that
variable, and I think it would be a kind of layer violation if it did.
Anyway, resolving the recurse<->depth question very soon after the
arrival of the protocol elements seems wise to me -- the further down
the code stack the duality is perpetuated, the more likely we are to
get into trouble later :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 9 07:54:16 2007