Vlad Georgescu <vgeorgescu@gmail.com> writes:
>> I think this means that r24493, r24468, and r24453 were mistaken. We
>> should be transmitting a depth from client to server, and remembering
>> it on the server side as the *requested* depth, not confusing it with
>> the *described* (default) depth.
>>
>> Does this analysis sound right to you?
>
> Yes, that's pretty much what I was thinking.
I'm relieved to hear that :-).
> How does this support the "upgrade" scenario? If you want to upgrade a
> working copy from, e.g, svn_depth_files to svn_depth_infinity, you have
> to get the (old) server to send you the complete subdirectories, not
> just updates. That's why I suggested the need to call delete-path on
> the missing stuff (to mark the subdirectories as missing in the working
> copy, telling the server to send fulltexts, not deltas).
>
> The problem here is that the depth-files working copy doesn't know the
> names of the subdirectories that it's missing, so you wouldn't be able
> to call delete-path on them.
>
> Hope I'm making sense here, the caffeine hasn't kicked in yet :).
Yes, you're making sense.
What if we use the 'start_empty' flag to set_path() and link_path()?
Is that the inverse we want, that is, like saying to the server
"assume all entries have been deleted, except for the ones I tell you
I have"? Specifically, I mean:
When the working directory has a depth other than svn_depth_infinity,
*and* we're upgrading it to a deeper depth, then pass start_empty=true
to reporter->set_path() / reporter->link_path(), and explicitly send
any entries that are present in the working copy.
If there's some way we can know that the server is 1.5 or higher, then
we can just send working depth, and not bother with start_empty=true
and with sending all the entries. But I don't know if enough of a
feature exchange will have taken place by the time we're talking to
the reporter.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 6 03:54:58 2007