Re: issue 1075 analysis [long] [for Philip!]

Ben Collins-Sussman <sussman@collab.net> writes:

> * WHERE are the danger points in our current codebase?
>
> Philip pointed out some risks last May: but I'm not so certain they
> exist anymore.

I tried a few things in gdb, the current code does appear to be
reasonably robust. I don't remember the May problem in detail, but I
think it applied to the code before the restartable checkout changes.
If that's the case then I think it is reasonable to assume that those
changes have eliminated the problem.

> In the final update walk, recursively_tweak_entries() is already
> doing all of the entries changes in memory. When the recursion
> permanently exits a directory, it writes *all* the entries-file
> changes to disk at once, as an atomic operation. That guarantees
> that every wc dir will be either in state #1 or #2 described above.
> No risk here.
>
> But I *do* see a a problem in the update-editor's close_dir(), where
> we're immediately marking a directory 'complete', yet taking no
> steps to remove *any* dead entries at all. I think that's the real
> problem that needs addressing.

Yes, that does go wrong. An interrupted update can end up with extra
entries, ones for which there are no items in the working copy and
which don't correspond to repository items. Status shows such extra
items as missing, and update will remove them. That behavior is not
too bad, it may even be acceptable.

> Philip (or others), can you confirm my analysis?

It looks reasonable. There is still this corner case

  $ svnadmin create repo
  $ svn co file://`pwd`/repo wc
  $ svn mkdir wc/foo
  $ rm -rf wc/foo # not svn rm
  $ svn up wc
  D wc/foo

Update shouldn't really delete the foo entry. I don't think this is a
particularly serious problem, it barely qualifies as a bug.

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