[BUG?] svn_fs__dag_remove_node does not cleanup all references to the deleted node

[Max Bowsher <ma...@ukf.net>]

When a node-rev is deleted from the fs (because it was added then deleted in
the same revision), svn_fs__dag_remove_node can leave behind references to
it in the copies and changes tables.

I haven't observed this causing any actual problems, except that if in the
future there is a tool which verifies the consistency of svn repositories,
it will find 'corruption'.

I think what needs to happen is:

* Scan the txn containing the node-rev for copies. Check each copy, if it
refers to the node-rev being removed, delete it from the copies table and
txn record.
* Scan the changes table and delete any change-records referring to the
node-rev being removed.


Comments?


Max.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [BUG?] svn_fs__dag_remove_node does not cleanup all references to the deleted node

[Max Bowsher <ma...@ukf.net>]

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

Re: [BUG?] svn_fs__dag_remove_node does not cleanup all references to the deleted node

["C. Michael Pilato" <cm...@collab.net>]

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [BUG?] svn_fs__dag_remove_node does not cleanup all references to the deleted node

[Max Bowsher <ma...@ukf.net>]

kfogel@collab.net wrote:
> "Max Bowsher" <ma...@ukf.net> writes:
>> When a node-rev is deleted from the fs (because it was added then deleted
in
>> the same revision), svn_fs__dag_remove_node can leave behind references
to
>> it in the copies and changes tables.
>>
>> I haven't observed this causing any actual problems, except that if in
the
>> future there is a tool which verifies the consistency of svn
repositories,
>> it will find 'corruption'.
>>
>> I think what needs to happen is:
>>
>> * Scan the txn containing the node-rev for copies. Check each copy, if it
>> refers to the node-rev being removed, delete it from the copies table and
>> txn record.
>> * Scan the changes table and delete any change-records referring to the
>> node-rev being removed.
>>
>> Comments?
>
> 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... ?
>
> -Karl

No, it is still a problem:

* Begin revision rN
* Add-with-history some-node copyfrom r(N-1)
* Delete some-node. Because still mutable,
    entirely deleted from 'nodes'
* End revision rN

Now 'copies' contains an entry with dest-node == the-deleted-node,
and 'changes' contains entries also referring to the-deleted-node.


Max.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [BUG?] svn_fs__dag_remove_node does not cleanup all references to the deleted node

[kf...@collab.net]

"Max Bowsher" <ma...@ukf.net> writes:
> When a node-rev is deleted from the fs (because it was added then deleted in
> the same revision), svn_fs__dag_remove_node can leave behind references to
> it in the copies and changes tables.
> 
> I haven't observed this causing any actual problems, except that if in the
> future there is a tool which verifies the consistency of svn repositories,
> it will find 'corruption'.
> 
> I think what needs to happen is:
> 
> * Scan the txn containing the node-rev for copies. Check each copy, if it
> refers to the node-rev being removed, delete it from the copies table and
> txn record.
> * Scan the changes table and delete any change-records referring to the
> node-rev being removed.
> 
> Comments?

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

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org