Re: Implement client side svn_depth_exclude support for cropping?

I am busy, yeah, but I do think that implementing svn_depth_exclude is
a reasonable idea. And also agree that it will end up spreading
throughout the code.

--dave

On Tue, Jun 10, 2008 at 11:45 PM, Rui, Guo <timmyguo_at_mail.ustc.edu.cn> wrote:
> 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
>
>

-- 
David Glasser | glasser@davidglasser.net | 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