I wrote:
> 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.
Okay, I have more thoughts on this. As I understand it, the locking
code wants to know what was deleted so it knows what kind of lock
check to perform. If the object deleted was a directory, then it
wants to check recursively for locks underneath the pathname in
question; if the object deleted was a file, it wants to check only for
a lock at the specific pathname.
However, the same logic applies if a node is replaced. If a directory
is replaced (with a directory or with a file), then the locking code
wants to check recursively; if a file is replaced (again, either with
a directory or with a file), then the locking code wants to check
singly.
But the changes table contains no information about what used to be
present when a node is replaced; it only says what new thing was put
there.
So, no amount of tweaking of what ID is recorded in "delete"
operations will satisfy the locking code; we would need to extend the
changes table to include both old and new IDs for "replace" operations
as well. (And if we do that, perhaps we want old and new IDs for
modifications for consistency, although the locking code doesn't care
because modifications can't change the type of a node.)
Short of making this data format change, the locking code must behave
conservatively, and perform a recursive check whenever it sees a
pathname replaced. Which means it may as well behave that way
whenever it sees a pathname deleted.
As an aside, CMike and I worked out a strategy for correctly recording
the old ID in deletes. It goes like this, for both FSFS and BDB:
* Reintroduce Ben's change on the branch (or keep it, if it hasn't
been reverted), so that a delete of a mutable node-revision
records the ID of the immutable predecessor of that node-revision.
* In txn_body_copy, record replacement operations as a delete + add,
not as a replace. The folding code will canonicalize this into a
replace under normal circumstances.
* When the folding code sees the first delete operation for a
pathname, make it remember what the ID was there. If the final
outcome for the pathname is a delete, use the ID from the first
delete operation, not the ID from the last one.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 11 10:21:43 2005