You have some useful points here; care to submit patches to the documentation?
On Mon, Mar 31, 2008 at 10:19 AM, Rui, Guo <timmyguo_at_mail.ustc.edu.cn> wrote:
> The sparse-directories document is a bit out-dated in several points, which
> is gotten cleared during the implementation later.
> The design section in that document refers to a "depth" in .svn/entries and
> a --depth option which sets the depth value. However, things have been
> changed. There are two different depths in the implementation. The first is
> the depth of the operation, and the second is just the one mentioned in the
> document, the depth of the WC. As a result, the examples of 'svn up --depth'
> in the document should be read as 'svn up --set-depth'.
> The following knowledge is not gained from the source code (not yet), but
> from the help message in the development-build (trunk r30114). Correct me if
> my statement is wrong.
> The depth of the operation limits the region affected by the operation. That
> is what the --depth option in command line actually means. Commands that
> accept a -N or -R switch in the old days are all modified to take a --depth
> option. A large majority (19 out of 33) of commands gets influenced, much
> more than the five listed in the "User interface" section of the document.
> The modification should be trivial for commands that do not affect the tree
> structure of WC and thus do not deserve further explanation. These take up
> 15 of the 19 affected commands. The last four commands which (may) need more
> attention are checkout, switch, update and merge. (PS: What does the
> chagelist command do? It seems to be a new command introduced in the develop
> There is a paragraph in the "Current Status" talking about the depth of
> On the server side, most of the significant changes are in
> libsvn_repos/reporter.c. The code that receives update reports now
> receives notice of paths that have different depths from their
> parent, and of course the overall update operation has a global
> depth, which applies whenever not shadowed by some local depth for
> a given path.
> <=========ENE OF QUOTE========>
> This describes how the depth of operation works. The "shadowed" means that,
> if a directory in WC is covered by the depth of operation, the depth of that
> local path will take control in the operation of the subtree. It implies
> that if there is a sub-directory A of infinity depth in current directory, a
> 'svn up --depth=immediates' will cover the whole subtree beneath A. I'm not
> sure if this applies to all other commands. The merge command should be
> quite different as described below.
> Both the switch and update command have a separate --set-depth option used
> to update the depth of WC, or the target of the command (such as current
> directory), to be more precise.
> However, the checkout command is a bit special. It takes only --depth option
> to both constrain the region of operation and set the depth of the WC. In
> other words, the semantic of --depth option in the checkout command is
> different the one in other commands. A clarification may be needed, either
> change a proper name or at least update the description of the option.
> The merge command is special that the modification made by this command is
> local to the WC and need to be committed. Thus the modification should be
> totally accepted by the WC. New subtree will be accepted in a depth of
> infinity. The depth of existing tree will not be modified. (Am I right? I'm
> not very sure about this.)
> How does the --set-depth option influence the subtree when some of the
> sub-directories have different depth from the root is an important question.
> The examples in the document do not cover this enough, more investigation is
> Rui, Guo
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
David Glasser | email@example.com | http://www.davidglasser.net/
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-31 22:12:44 CEST