issue 1075 analysis [long] [for Philip!]

Philip (and others):

I spent most of yesterday studying wc code and issue #1075.
Technically, the original bug is already fixed. But the issue was
reopened last May, because Philip pointed out some risks of getting an
inconsistent working-copy (should one interrupt an update.)

I think the codebase has changed a lot since then, and if possible,
I'd like people to confirm my analysis of what risks still
exist... especially Philip.

I've tried to organize my thoughts below.

Issue #1075: proper cleanup of 'dead' entries.

* 'dead' entry definition:

   An entry (pointing to a subdirectory) which was reported 'missing'
   during an update, but the server *wanted* it to be gone, so said
   nothing about it... i.e. dir_delta() did not re-send the subdir,
   because the working copy transaction already matched the revision.

   There are two types of dead entry:

     type 1 - the kind that arises from: 'rm -rf subdir; svn up'
              (the 'missing' subdir is never restored by the server.)

     type 2 - the kind that arises from: 'svn rm subdir; svn commit; svn up'
              (the commit creates a famous 'deleted' entry.)

   Because the server never restored the subdirectory, the client has
   the responsibility of noticing/removing the dead entry. (I know
   that others have debated this design, but I'd rather not open that
   can of worms at the moment. The current system is working pretty
   well already, and I just want to make sure being done safely.)
   

* Where/when should dead-entry cleanup happen?

   That's tricky. Certainly, dead entry cleanup needs to happen
   -before- a directory is marked 'complete' by the update editor's
   close_directory(). Otherwise it's possible for the completeness to
   be a lie -- there's an extra entry lying around.

   But what about dead entries living outside the scope of the editor
   drive? The update process always ends with a complete walk of the
   *entire* working copy... the walk bumps working revs everywhere,
   and has ample opportunity to remove dead entries as well.

   However, if we interrupt the update in the middle of this final
   walk, we want to make sure that a directory is consistent, that is:

      1. the directory still claims to be at the old revision, with
         dead-entries still present. That's fine; 'svn status' will
         correctly show the items as 'missing'.
        
      OR

      2. the directory claims to be at the new revision, with all
         dead-entries removed.

   The final-walk process is responsible for guaranteeing that each wc
   directory will be in one of these two consistent states, should an
   interruption happen.

* 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.

  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.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 25 19:45:39 2003