Brian Denny <brian@briandenny.net> writes:
> On Mon, May 05, 2003 at 09:11:25PM -0500, cmpilato@collab.net wrote:
> >
> > And I still disagree with you. The only problem with this patch is
> > the timing of this cleanup. The removal of missing items needs to
> > happen at the same time as the bumping of the directory version
> > number. When I originally came up with this solution, my idea was
> > that this cleanup code would occur in two places:
> >
> > (1) the update_editor's close_dir() (which might require a new loggy
> > operation)
> > (2) the global post-update revision bump (do_update_cleanup).
>
>
> in recursively_tweak_entries, we call svn_wc__tweak_entry with the new
> revnum. is that what you're referring to in (2) above?
>
> the update_editor's close_directory function calls maybe_bump_dir_info,
> which looks like it also (potentially) changes the revnum? is that why
> the removal of missing items needs to happen in the case of (1)?
>
> why do we need to have these two separate places in the code that bump
> the revnum?
>
> (for that matter, i don't really understand the difference between
> close_directory and close_edit -- i mean, i understand that close_edit
> is only called once at the end, where close_directory might be called on
> any directory being visited along the way... but why do some operations
> have to happen at the one time, and others at the other?)
The answer to several of these questions is the same -- state
validity. We do our darnedest in Subversion to make it as resilient to
nasty situations as possible, where "nasty situations" includes such
things as network and power outages that might happen in the middle of
an operation. Obviously, it's not likely that we'll do a perfect job
with this, but it doesn't mean we won't try.
To be specific, there are several places where we bump the revision of
a directory because those are places where it is safe to do so, and
because *not* doing so would result in a working copy whose
administrative data is bogus. For example, after closing an updated
directory, we want to bump its revision because if the update were to
fail immediately thereafter, we'd like to be able to just run 'svn up'
again and continue the process of getting our working copy updated to
HEAD. If we hadn't bumped the revision number, we would have a
directory that claims to be at some revision when in fact all of its
contents are proof that, no, we most certainly don't have the revision
of the directory we claim to have.
This is also the reason we have the svn_wc__log_* functions. It's
essentially our implementation of a journaling filesystem, where one
or more actions are scheduled to be -- well, acted out -- and then
later we actually act those actions. :-) The idea here is that if
something goes wrong in the middle of playing out the tasks in the log
file, when you run 'svn cleanup' Subversion will try those loggy
actions again in an attempt to get your working copy into a sane
state.
--
Wow. I feel like I just wrote a section that should be included in
Chapter 7 of the book (the Development chapter).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 6 06:41:20 2003