You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2007/05/09 07:23:35 UTC
[PATCH] Describing depth/recurse concepts in the RA layer
Karl, Vlad, et at:
Okay, it's not *really* a patch. I was trying to keep my thinking straight
regarding all the depths and recursion flags flying across the RA layer.
The following is what I worked up. Can you guys review it for sanity and
correctness? If it's accurate, I'd like to put this (or something like it)
into the sparse-directories.txt file.
--------------------------------------------------------------------------
PRE-1.5 CLIENTS
Pre-1.5 clients will never transmit reported depths and never
transmit a requested depth. But they will (perhaps optionally,
depending on the RA layer) transmit a requested recurse (either
'yes' or 'no', with 'yes' being the default).
When speaking to a pre-1.5 server, what happens happens. It's the past,
man -- you don't get to define it now.
When speaking to a 1.5 server, the not-reported depths are treated
like reported depths of 'infinity', and the recurse 'yes' and 'no'
map to depths of 'infinity' and 'files', respectively.
1.5 CLIENTS
1.5 clients will transmit reported depths (with 'infinity' as the
default) and will transmit a requested depth (with 'unknown' as the
default). They will also -- for the sake of older, non-depth-aware
servers -- transmit a requested recurse, mapped from requested
depths ('empty' or 'files' = no; 'unknown', 'immediates', and
'infinity' = yes).
When speaking to a pre-1.5 server, the requested recurse is the only thing
the server notes, but is obviously more "grainy" than the depth concept.
The client, therefore, must filter out unwanted data that the server
transmits.
When speaking to a 1.5 server, the requested recurse is ignored. A
requested depth of "unknown" means "only send information about the
stuff in my report, depth-aware-ily". Other depths are honored by
the server properly, and the client must handle the transformation of
any working copy depths from their pre-update to their post-update
depths and content.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: [PATCH] Describing depth/recurse concepts in the RA layer
Posted by "C. Michael Pilato" <cm...@collab.net>.
Karl Fogel wrote:
> "C. Michael Pilato" <cm...@collab.net> writes:
>> PRE-1.5 CLIENTS
>>
>> Pre-1.5 clients will never transmit reported depths and never
>> transmit a requested depth. But they will (perhaps optionally,
>> depending on the RA layer) transmit a requested recurse (either
>> 'yes' or 'no', with 'yes' being the default).
>>
>> When speaking to a pre-1.5 server, what happens happens. It's the past,
>> man -- you don't get to define it now.
>>
>> When speaking to a 1.5 server, the not-reported depths are treated
>> like reported depths of 'infinity', and the recurse 'yes' and 'no'
>> map to depths of 'infinity' and 'files', respectively.
>
> Amen to all that.
>
>> 1.5 CLIENTS
>>
>> 1.5 clients will transmit reported depths (with 'infinity' as the
>> default) and will transmit a requested depth (with 'unknown' as the
>> default). They will also -- for the sake of older, non-depth-aware
>> servers -- transmit a requested recurse, mapped from requested
>> depths ('empty' or 'files' = no; 'unknown', 'immediates', and
>> 'infinity' = yes).
>
> When a 1.5 client has no requested depth, does it still transmit
> recurse=yes in those RA layers that today transmit recurse=yes by
> default?
I dunno -- I was trying to imply by noting the presence of default values
that the info was *effectively* transmitted (insomuch as "not transmitting
recurse=no" is effectively the same as transmitting recurse=yes) more so
than that the protocol contained literal embeddings of these values. Maybe
I should make that more clear.
>> When speaking to a pre-1.5 server, the requested recurse is the only thing
>> the server notes, but is obviously more "grainy" than the depth concept.
>> The client, therefore, must filter out unwanted data that the server
>> transmits.
>>
>> When speaking to a 1.5 server, the requested recurse is ignored. A
>> requested depth of "unknown" means "only send information about the
>> stuff in my report, depth-aware-ily". Other depths are honored by
>> the server properly, and the client must handle the transformation of
>> any working copy depths from their pre-update to their post-update
>> depths and content.
>
> Say "Other requested depths are honored by the server properly..."
> ^^^^^^^^^
> ...just to be clear :-).
Heheh. Yes! +1 on clarity (since that is, after all, the point of the
exercise).
> This whole last paragraph looks correct to me, but the meaning of the
> first sentence might be clearer if expanded to this:
>
> "When a 1.5 server receives both requested depth and recurse, the
> recurse is ignored in favor of the depth, even when the depth is
> svn_depth_unknown. But when a 1.5 server receives recurse with no
> requested depth, it honors the recurse, on the theory that it's
> talking to a pre-1.5 client."
>
> (You've sort of organized your text around the client version, but we
> really need to talk about server behavior in detail for the reader to
> fully grok what's going on, IMHO.)
Okay. I think this ties into the fact that I was talking more about the
implicit data transfer than the literal. But I agree that there is value in
recording how the literal gets translated into the effective.
I'll adjust and commit, and review/adjustment can be made on the committed
stuffs.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: [PATCH] Describing depth/recurse concepts in the RA layer
Posted by Karl Fogel <kf...@red-bean.com>.
"C. Michael Pilato" <cm...@collab.net> writes:
> PRE-1.5 CLIENTS
>
> Pre-1.5 clients will never transmit reported depths and never
> transmit a requested depth. But they will (perhaps optionally,
> depending on the RA layer) transmit a requested recurse (either
> 'yes' or 'no', with 'yes' being the default).
>
> When speaking to a pre-1.5 server, what happens happens. It's the past,
> man -- you don't get to define it now.
>
> When speaking to a 1.5 server, the not-reported depths are treated
> like reported depths of 'infinity', and the recurse 'yes' and 'no'
> map to depths of 'infinity' and 'files', respectively.
Amen to all that.
> 1.5 CLIENTS
>
> 1.5 clients will transmit reported depths (with 'infinity' as the
> default) and will transmit a requested depth (with 'unknown' as the
> default). They will also -- for the sake of older, non-depth-aware
> servers -- transmit a requested recurse, mapped from requested
> depths ('empty' or 'files' = no; 'unknown', 'immediates', and
> 'infinity' = yes).
When a 1.5 client has no requested depth, does it still transmit
recurse=yes in those RA layers that today transmit recurse=yes by
default?
> When speaking to a pre-1.5 server, the requested recurse is the only thing
> the server notes, but is obviously more "grainy" than the depth concept.
> The client, therefore, must filter out unwanted data that the server
> transmits.
>
> When speaking to a 1.5 server, the requested recurse is ignored. A
> requested depth of "unknown" means "only send information about the
> stuff in my report, depth-aware-ily". Other depths are honored by
> the server properly, and the client must handle the transformation of
> any working copy depths from their pre-update to their post-update
> depths and content.
Say "Other requested depths are honored by the server properly..."
^^^^^^^^^
...just to be clear :-).
This whole last paragraph looks correct to me, but the meaning of the
first sentence might be clearer if expanded to this:
"When a 1.5 server receives both requested depth and recurse, the
recurse is ignored in favor of the depth, even when the depth is
svn_depth_unknown. But when a 1.5 server receives recurse with no
requested depth, it honors the recurse, on the theory that it's
talking to a pre-1.5 client."
(You've sort of organized your text around the client version, but we
really need to talk about server behavior in detail for the reader to
fully grok what's going on, IMHO.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org