On Sat, Jun 14, 2008 at 08:57:56PM -0400, Karl Fogel wrote:
> firemeteor_at_tigris.org writes:
> > Log:
> > On issue-2843-dev branch.
> >
> > Make 'svn update' honors the svn_depth_exclude flag. It works for clean wc
> > now. And all existing test suites remained working. Hoever, the crawler has
> > not been updated yet. So, filtering modification in the excluded branch will
> > not work now.
>
> I didn't understand the last sentence above. Do you mean that the
> svn_depth_exclude conditional branch will not be reached?
I did not report the excluded path to repository, and thus the server will
send modification in the excluded path. That's all. The modification will be
blocked by ambient_depth_filter_editor though. But that is another story.
>
> > The svn_wc_entry() and svn_wc_entries_read() now filter out excluded
> > item when show_hidden is FALSE.
> >
> > [in subversion/libsvn_wc]
> >
> > * svn_wc.h, entries.c, lock.c
> > (svn_wc_entry, svn_wc_entries_read, svn_wc_walk_entries3): Document the
> > new filter behavior.
> > (read_entries, prune_deleted): Implement the documented behavior.
>
> Oops, don't mix files together unless they contain exactly the same
> symbols (function names, variable names, etc). I know svn_wc.h has all
> the symbols, but then they are split across the two .c files.
Sorry. And thanks for update the log message for me.
PS: propedit on log message seems tend to timeout at the first try. I didn't
notice this on update and commit. Does it takes more time for the server to
response such a request?
>
> > --- branches/issue-2843-dev/subversion/libsvn_wc/adm_ops.c (r31712)
> > +++ branches/issue-2843-dev/subversion/libsvn_wc/adm_ops.c (r31713)
> > @@ -129,7 +129,8 @@ tweak_entries(svn_wc_adm_access_t *dirpa
> > /* If a file, or deleted or absent dir, then tweak the entry
> > but don't recurse. */
> > if ((current_entry->kind == svn_node_file)
> > - || (current_entry->deleted || current_entry->absent))
> > + || (current_entry->deleted || current_entry->absent
> > + || current_entry->depth == svn_depth_exclude))
> > {
> > if (! excluded)
> > SVN_ERR(svn_wc__tweak_entry(entries, name,
>
> Want to adjust the comment too?
Done.
>
> Suggest parens for clarity: exclude = (entry == NULL);
>
> > + }
> > + else
> > + {
> > + /* If the parent expect all children by default, only exclude
> > + it whenever it is explicitly marked as exclude. The
> > + svn_depth_unknown means that: 1) pb is the anchor; 2) there
> > + is an non-null target, for which we are preparing the baton.
> > + This enables explicitly pull in the target. */
> > + exclude = entry && entry->depth == svn_depth_exclude;
>
> Same.
Done.
>
> > --- branches/issue-2843-dev/subversion/libsvn_wc/update_editor.c (r31712)
> > +++ branches/issue-2843-dev/subversion/libsvn_wc/update_editor.c (r31713)
> > @@ -473,7 +473,23 @@ complete_directory(struct edit_baton *eb
> > /* If this is the root directory and there is a target, we can't
> > mark this directory complete. */
> > if (is_root_dir && *eb->target)
>
> This isn't your code, but I see a lot of "if (*eb->target)" in this
> file, which makes me think that when there is no target, eb->target is
> "" rather than NULL. Which is fine, but we should document that in
> struct edit_baton!
It should have been ensured by svn_wc_adm_open_anchor(), I think. The document
about anchor in notes/ directory has some words on it, if I recall correctly.
>
> > @@ -541,21 +557,27 @@ complete_directory(struct edit_baton *eb
> > {
> > const char *child_path = svn_path_join(path, name, subpool);
> >
> > - if ((svn_wc__adm_missing(adm_access, child_path))
> > - && (! current_entry->absent)
> > - && (current_entry->schedule != svn_wc_schedule_add))
> > + if (current_entry->depth == svn_depth_exclude)
> > {
> > - svn_wc__entry_remove(entries, name);
> > - if (eb->notify_func)
> > - {
> > - svn_wc_notify_t *notify
> > - = svn_wc_create_notify(child_path,
> > - svn_wc_notify_update_delete,
> > - subpool);
> > - notify->kind = current_entry->kind;
> > - (* eb->notify_func)(eb->notify_baton, notify, subpool);
> > - }
> > - }
> > + /* Clear the exclude flag if it is pulled in again. */
> > + if (eb->depth_is_sticky
> > + && eb->requested_depth >= svn_depth_immediates)
> > + current_entry->depth = svn_depth_infinity;
>
> The 'current_entry' here is just the parent's entry for the subdir,
> right? And therefore the only reason we're using svn_depth_infinity is
> so that that subdir entry won't write out an explicit depth, and the
> subdir itself will know its own actual depth? (Just checking my own
> understanding.)
Yes. The depth field was only stored in this_dir entry. And I extend it
that the subdir entry may have an 'exclude' depth value indicating that it is
cropped out. However, the old depth values are still handled in the usual
way.(in other words, restrictive values other 'exclude' is not allowed in
subdir entries. May I explicitly check this in read_entry()?)
Rui
---------------------------------------------------------------------
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-15 08:39:01 CEST