Greg Stein <gstein@lyra.org> writes:
> On Tue, Aug 21, 2001 at 04:10:23PM -0000, sussman@tigris.org wrote:
> > User: sussman
> > Date: 01/08/21 09:10:23
> >
> > Modified: subversion/libsvn_wc adm_crawler.c
> > Log:
> > * adm_crawler.c (svn_wc_crawl_local_mods): replace all SVN_ERR calls
> > with blocks that cleanup lockfiles. This might resolve a
> > locked-working-copy bug seen in very large commit tests. Thanks to
> > Yoshiki Hayashi <yoshiki@xemacs.org> for noticing this problem.
>
> A more robust solution would be to have svn_wc_crawl_local_mods create the
> hash table and pass it into do_crawl_mods() (or whatever). When
> do_crawl_mods() returns, then the locks are cleared and the (error) result
> returned.
I absolutely agree -- there should be exactly one "checkpoint" that
will catch *any* error thrown during a commit-crawl. This one
checkpoint should then free any locks.
However, I couldn't figure out how to do this.
The problem is the structure of the public routine. Here's an outline:
svn_wc_crawl_local_mods(dir)
{
locks = apr_hash_make();
if (no targets)
err = crawl_dir(dir, locks)
else
{
loop over many targets:
{
[lots of complex stack crawling logic to get to next target...]
[lots of SVN_ERR macros around calls to helper routines...]
err = report_single_mod(target, locks);
}
err = do_dir_closures()
err = editor->close_dir(root)
}
err = do_postfix_text_deltas()
err = editor->close_edit()
remove_all_locks()
}
Note that there's complementary recursion going on too:
report_single_mod() and crawl_dir() call one another.
Looking at this structure, what do you suggest? That we rename this
public function to some internal name, and make
svn_wc_crawl_local_mods() a "wrapper" around the whole thing, whose
only purpose is to catch errors and cleanup locks? I'm amenable to
that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:36 2006