[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn_client__checkout_internal and depth comment/code inconsistency

From: Vlad Georgescu <vgeorgescu_at_gmail.com>
Date: 2007-07-16 17:49:45 CEST

Karl Fogel wrote:
> However, first svn_client__update_internal() needs to actually grok
> the existing working copy depth, for the resuming-a-checkout case.
> Here's why: if someone resumes a checkout, they might assume that the
> partial working copy will remember the depth the tree is supposed to
> have -- and if they don't pass an explicit depth, that's equivalent to
> 'svn_depth_unknown'. svn_client__update_internal() is what gets
> invoked from the checkout code when resuming an interrupted checkout,
> so it needs to DTRT with 'svn_depth_unknown' and grok the depth from
> the working copy.
>

I don't think any changes are necessary to svn_client__update_internal().

The argument to svn_client__update_internal() is the _requested_ depth
that is sent to the server when starting the update. This depth *can*
be svn_depth_unknown, because the server also uses the depths from the
individual set-path/link-path reporter calls to determine what to send
back to the client.

svn_depth_unknown is just a way of saying to the server "I'll tell you
what's in my working copy, send me updates for just those paths". For
example, if someone does a checkout at depth-files and also brings in a
subdirectory, "svn update" will pull changes for all files *and* the
subdirectory.

When resuming an interrupted checkout, the requested depth will be
svn_depth_unknown, but the set-path for the root dir will report the
depth of the original checkout, and the server will DTRT.

-- 
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 16 17:49:22 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.