No response huh? Seems everybody is busy.
On Tue, Jun 10, 2008 at 02:29:46PM +0800, Rui, Guo wrote:
> 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
>
---------------------------------------------------------------------
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-11 08:45:32 CEST