questions about 'bdi' objects in update_editor.c

[Ben Collins-Sussman <su...@collab.net>]

kfogel, this question is probably for you, but maybe someone else can
answer.

If you look at update_editor.c, notice that we have the 'bump' objects
called 'bdi'.  They're essentially tiny little structures that mirror
the dir_batons, which are much larger.  When close_dir() is called,
the dir_batons are freed, but the bdi structures remain, and
maybe_bump_dir_info() uses the bdi structures to keep track of
directory refcounts and 'bump' a directory whenever its refcount hits
zero.

(The refcounting stuff is because of postfix text-deltas, whereby a
directory may be closed while not-yet-closed file-batons still exist
that point to it.  Kinda silly, considering that NOBODY (yet) sends
postfix textdeltas into this update_editor.  :-) )

Anyway, the bdi structures are created right along side the
dir_batons, within make_dir_baton().  Notice the interesting logic in
there: both the dir_baton and bdi structure share a 'new_URL' field,
which is the URL the directory represents.  Notice that this variable
is created by sometimes telescoping an ancestor_url, and other times
telescoping a switch_url.

Before I started making restartable checkout changes (pre-5928),
maybe_bump_dir_info() would notice when a directory refcount hit zero,
and do two things:  change the directory's revnum from '0' to
something valid, and install the new_URL.

In my recent changes (r5928+), add_directory() installs a valid
revision and URL (inherited directly from the parent) immediately, and
adds an 'incomplete' flag.  I changed maybe_bump_dir_info() to simply
remove the 'incomplete' flag.

... so now the bdi->new_URL value is going completely unused.  Same
with dir_baton->new_URL, as far as I can tell.  The fruits of the
telescoping logic aren't being used anymore.

Is this situation broken?  Am I messing something up here?  I would
have expected 'svn switch' to break, perhaps, since 'new_URL' is no
longer being installed anywhere... but that's not the case.  Maybe
that post-update crawling code is fixing up the urls for me?  (In
which case, can I just remove all the 'new_URL' stuff everywhere?)

Can someone shed some light here?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: questions about 'bdi' objects in update_editor.c

[kf...@collab.net]

Ben Collins-Sussman <su...@collab.net> writes:
> Before I started making restartable checkout changes (pre-5928),
> maybe_bump_dir_info() would notice when a directory refcount hit zero,
> and do two things:  change the directory's revnum from '0' to
> something valid, and install the new_URL.
> 
> In my recent changes (r5928+), add_directory() installs a valid
> revision and URL (inherited directly from the parent) immediately, and
> adds an 'incomplete' flag.  I changed maybe_bump_dir_info() to simply
> remove the 'incomplete' flag.
> 
> ... so now the bdi->new_URL value is going completely unused.  Same
> with dir_baton->new_URL, as far as I can tell.  The fruits of the
> telescoping logic aren't being used anymore.
>
> Is this situation broken?  Am I messing something up here?  I would
> have expected 'svn switch' to break, perhaps, since 'new_URL' is no
> longer being installed anywhere... but that's not the case.  Maybe
> that post-update crawling code is fixing up the urls for me?  (In
> which case, can I just remove all the 'new_URL' stuff everywhere?)
>
> Can someone shed some light here?

Let's talk about this in person.  I don't think anything's broken
here, at least for regular updates -- we install the URL right away
now, so no need for bdi to do it during the refcount bump phase.  But
your question about switch makes me wonder when the URLs are getting
changed during that operation.  I *think* it's happening cleanly: each
individual file in a dir gets its URL updated, then the last thing we
do is the dir, but we should check that...


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org