C. Michael Pilato wrote:
> kfogel@collab.net writes:
>
>> It shouldn't be possible for a copy to have a source in the same
>> revision in which the copy is committed. That is, the "history" in an
>> add-with-history can only refer to nodes in committed revisions, not
>> new nodes in the same txn as the add.
>>
>> So, this shouldn't be a problem... ?
>
> No, Max's point is that we never remove anything from the changes
> table or copies table unless the transaction is aborted. So, because
> you can repeatedly add and delete the same path within a single
> transaction, each of those additions and deletions gets a 'changes'
> table line -- but by the end of it all, most of the node-ids referred
> to in those changes no longer exist. The same problem occurs with
> copies -- if you do "copy foo bar, delete bar, copy foo bar, delete
> bar..." we'll have 'copies' table rows that refer to node-ids that
> have already been removed.
Yes. Would you say the correct solution is to do this?:
* On deleting a node.
* Scan the 'changes' for the current txn, removing any rows containing the
deleted node.
* Scan the 'copies' associated with the current txn, and delete any
referring to the deleted node, from both the 'copies' table, and the txns
entry in 'transactions'.
A problem is that libsvn_fs/bdb/changes-table.{h,c} currently offers no
interface for deleting individual changes elements - only all for the txn.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 15 21:23:31 2004