Re: commit logic.

Jim, you wanted some kind of "proof" that it's okay to call
svn_fs_copy inside of replace_dir() and replace_file(). Let me see if
I can summarize here.

We're crawling a local copy and are in directory D, at revision N. We
notice an entry E needs to be committed, but E is at revision M. The
driver calls replace_*(E, baserev=M).

On the editor side, is it valid to call svn_fs_copy(M, /path/to/D/E,
txn, /path/to/D/E)? How do we know that the path to E in M is the
*same* as the path in E in N?

Proof by contradiction: assume that the path to E is M is *not* the
same as the path to E in N.

How did the user end up with their working copy state?

  1. The user had revision N of E, changed E, committed, thereby
      creating revision M, and resulting in only E being
      revision-bumped. But then the paths to E would be the same in
      both revisions. Contradiction.

  or

  2. The user selectively updated E, not its parent. But in updating
      E to M, the filesystem *must* have been been able to find E in
      the same location as in N. (Else it would have returned
      out-of-date error.) Thus the paths are the same in N and M.
      Contradiction.

Jim, is this the proof you were looking for? Are we out of the
theoretical woods? :)
Received on Sat Oct 21 14:36:26 2006