I'm seriously consider implementing client side svn_depth_exclude support now.
It gives a complete solution to cut off the root of the target tree, along
with all its children. By contrast, my previous design of using
svn_depth_empty works only when the parent of target is in
svn_depth_empty/files, and conflicts with the conventional semantics of 'svn
up --set-depth empty'.
However, the client side support of svn_depth_exclude will be a big job. I
estimate the following influence:
1. The format of the entries file. The depth field is meaningful only for the
'this_dir' entry in current version. However, the excluded sub-dir will not
have an adm-dir to store the needed information. So, we have to introduce an
'excluded' field or just let the sub-dir entries have a meaningful depth value
if and only if it is excluded. Which is better, huh? (I prefer the latter) We
may also have to update the format version number and corresponding document.
2. The --depth option must reject the depth value svn_depth_exclude, since it
is meaningless to use 'exclude' as an operative filter. We may have to add
sanity check in both libsvn_wc or libsvn_client. Most of the svn subcommands
will be affected. However, we must get ready for excluded targets. In such a
situation, the svn_wc_entry() call will not return the 'this_dir' entry of the
target or a NULL value. Instead, we will get a corresponding entry in the
parent directory, which contains little information besides the exclude flag.
This implies that, we may have to check the exclude flag each time
svn_wc_entry() is called. Or, we may modify the svn_wc_entry() to just ignore
the excluded entry? Or, introduce a 'show_excluded' flag? Reuse the
'show_hidden' flag? Many choices are possible. Which one is better?
Ths svn_wc_read_entries() may have the same problem.
3. Update ambient_depth_filter_editor to filter out svn_depth_exclude? I'm not
sure of this.
4. Update those routines that crawling through the wc trees to honor
svn_depth_exclude. These may include svn_wc_walk_entries3(),
svn_wc_crawl_revisions3(), harvest_committables() and much more. Some of the
modifications may be handled through the entry interface described in the
second point, others may still need to be done locally in the crawling logic.
5. New test cases, of cause.
In summary, adding support to svn_depth_exclude will lead to modifications
that spread out the whole code base of libsvn_wc (and libsvn_client?).
Experience is needed to figure out the right place to modify. So, I need your
help to locate the possible modifications. Could you point them out for me?
(Just tell me which part of the logic is suspicious.)
Thank you very much!
Rui, Guo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-10 08:30:00 CEST