On Mon, Jun 29, 2009 at 04:14:10PM +0800, yellow.flying wrote:
> Hey,
>
> I find the following comment in svn_types.h:
>
> /* The order of these depths is important: the higher the number,
> the deeper it descends. This allows us to compare two depths
> numerically to decide which should govern. */
>
> But in function svn_client_commit4() the levels_to_lock is svn_depth_exclude( =-1)
> when locking recursively while the levels_to_lock is svn_depth_empty( =0) when
> locking non-recursively. Is not it deeper when locking recursively? But why its
> levels_to_lock is smaller than when locking non-recursively.
>
> I am a little confused here:(
levels_to_lock is not the same as "depth".
In fact, levels_to_lock is just an integer, not svn_depth_t.
levels_to_lock is a parameter to svn_wc_adm_open3(), the docstring for
which says:
* @a levels_to_lock specifies how far to lock. Zero means just the specified
* directory. Any negative value means to lock the entire working copy
* directory hierarchy under @a path. A positive value indicates the number of
* levels of directories to lock -- 1 means just immediate subdirectories, 2
* means immediate subdirectories and their subdirectories, etc.
(See include/svn_wc.h).
So levels_to_lock controls how we lock the .svn directories in our
working copy:
-1 => .svn and */.svn and */*/.svn and ... and */*/*/*/.../*/.svn
0 => Only .svn
1 => .svn and */.svn
2 => .svn and */.svn and */*/.svn
3 => .svn and */.svn and */*/.svn and */*/*/.svn
(Recall that the .svn directories are also called "admin
areas", for which we need an "adm_access" ("admin access") baton when
we want to change it. That's what the adm_access stuff is for and what
the locking stuff is about.)
The "depth" says something different. During commit, depth is used
to control how the commit target list is interpreted:
This is from the docstring of svn_client_commit4():
* If @a depth is @c svn_depth_infinity, commit all changes to and
* below named targets. If @a depth is @c svn_depth_empty, commit
* only named targets (that is, only property changes on named
* directory targets, and property and content changes for named file
* targets). If @a depth is @c svn_depth_files, behave as above for
* named file targets, and for named directory targets, commit
* property changes on a named directory and all changes to files
* directly inside that directory. If @c svn_depth_immediates, behave
* as for @c svn_depth_files, and for subdirectories of any named
* directory target commit as though for @c svn_depth_empty.
So depth is independent of locking.
Locking is done so we can get admin access batons for each .svn directory
in the working copy.
Depth is used to control how we interpret the target path list.
We can map from depth to levels to lock as follows:
depth infinity: Commit everything recursively, so lock everything,
so levels_to_lock is -1, .svn and */.svn and */*/.svn and
... and */*/*/*/.../*/.svn
depth empty: Commit only targets _specified_ (only property changes on
specified directories, property changes and content changes
on specified files). So for each target in the list,
levels_to_lock can be 0 so that we just lock the target's .svn.
depth files: Like "depth empty", except that for directories, also commit
changes to files inside the directory. Again, we need to lock
only the targets we are committing, so levels_to_lock can be 0,
so that we just lock .svn.
depth immediates: Like "depth files", but for any named directory commit
property changes on any of its subdirectories.
So we need to lock up to level 1 (recall that level 0 is
the current level), so levels_to_lock can be 1, so that
we lock .svn and */.svn for each target.
But in practice, the code is lazy and only uses -1 (lock everything)
or 0 (lock just .svn), as explained in this comment inside of
svn_client_commit4():
/* When svn_path_condense_targets() was written, we didn't have real
* depths, we just had recursive / nonrecursive.
*
* Nowadays things are more complex. If depth == svn_depth_files,
* for example, and two targets are "foo" and "foo/bar", then
* ideally we should condense out "foo/bar" if it's a file and not
* if it's a directory. And, of course, later when we get adm
* access batons for the commit, we'd ideally lock directories to
* precisely the depth required and no deeper.
*
* But for now we don't do that. Instead, we lock recursively from
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* base_dir, if depth indicates that we might need anything below
* there
So the code isn't as precise as it could be about locking.
It locks more than it needs to lock, but that does not hurt :)
Is it clear now?
Stefan
Received on 2009-06-29 13:13:13 CEST