On Wed, 2005-02-09 at 15:54, Ben Collins-Sussman wrote:
> Hey fsfs experts -- cmpilato fears that fsfs may have this same logic
> bug, regarding the recording of changes. Maybe you can take a look.
FSFS has the same issue.
Unfortunately, r12956 does not produce the correct answer in all
circumstances. There is an even screwier case, identified (mostly) by
Max, which is to do the following, all within a single transaction:
delete a/b (a/b was a directory)
copy some/other/path a/b (some/other/path is a file)
delete a/b
r12956 will record the node-ID of some/other/file in the delete
operation. So we now have a transaction whose effect is to delete a
directory at a/b, but whose changes table says it deleted the node-ID of
some file. To determine the node ID we want to record, we would have to
do something find ugly, like find the old changes entry where a/b was
first deleted, or read the directory information from the predecessor of
the parent directory.
On IRC, I suggested that maybe the locking code should do a path lookup
at the base-rev of the transaction, but Mike pointed out that that isn't
so easy, since some parent directory of a/b may itself have been a copy.
I feel like the locking code should not need to know the type of object
which was deleted in order to work correctly, and that the designers
have wandered down the wrong path somewhere. But I don't have my head
wrapped around the locking code completely, so I can't say exactly where
I think the wrong turn was.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 9 23:23:25 2005