The default svn ChangeCollector information about deleted paths is incomplete

[cboos]

eblot reported that a svn remove below a folder just copied in the working copy (the copy being not yet committed) is wrongly reported by Trac as happening below the source of the copy.

i.e.

$ svn cp ../vendor/zlib packages/zlib
$ svn rm packages/zlib/Makefile
$ svn ci 
Committed revision 2099.

is stored in node_change as:

...
2099|vendor/zlib/Makefile|F|D|vendor/zlib/Makefile|2098

whereas it should have been something like:

...
2099|trunk/packages/zlib/Makefile|F|D|vendor/zlib/Makefile|2098

The problem is that we're using the default ChangeCollector from the svn.repos module, which deliberately omits this information: see  repos.py.

So we should instead use our own change collector.

[cboos]

Another example of this behavior was reported in #5921.

[cboos]

Well, I'm having a second look at that, the information we need is actually available from the ChangeCollector, it's simply the path used as a key for the change.

[cboos]

Work in progress: the deleted entries look now ok in the node_change table, but the displayed info in the templates has yet to be updated. Also, there are 4 regressions in the tests which heavily suggest that this is not the final fix ;-)

[cboos]

Ok, I think I have a fix, but this will require some incompatible API change: propagating the right path information for DELETE changes in Repository.get_changes(), in the same way it's done in Changeset.get_changes().

So this will have to wait for milestone:0.12.

[anonymous]

This problem affects me too, as it stops the  http://trac-hacks.org/wiki/RevtreePlugin working properly when copying+deleting at the same txn. Adding myself to the CC list.

[eblot]

Replying to anonymous:

This problem affects me too, as it stops the  http://trac-hacks.org/wiki/RevtreePlugin working properly when copying+deleting at the same txn. Adding myself to the CC list.

I'm not sure both issues are related (it depends on the actual operations):  th:RevtreePlugin does not / will not support copy+delete operations in distinct branches - only within the same branch.

[anonymous]

My problem is more as #5921 explains, but that ticket was marked as a duplicate of this one.

My copy+delete ARE within one (new) branch, but node_change says they are not (which is wrong --- svn log -v shows they are all within a branch)

sqlite> select * from node_change where rev = "1009";
1009|branches/releases/customer1/3.3.3.1|D|C|trunk|1008
1009|trunk/conf/customer2|D|D|trunk/conf/customer2|1008
1009|trunk/conf/customer3|D|D|trunk/conf/customer3|1008
1009|trunk/conf/customer4|D|D|trunk/conf/customer4|1008

while

r1009 | pipern | 2007-08-28 12:18:02 +0100 (Tue, 28 Aug 2007) | 1 line
Changed paths:
   A /branches/releases/customer1/3.3.3.1 (from /trunk:1008)
   D /branches/releases/customer1/3.3.3.1/conf/customer2
   D /branches/releases/customer1/3.3.3.1/conf/customer3
   D /branches/releases/customer1/3.3.3.1/conf/customer4

Branch trunk at head for customer1 3.3.3.1

[cboos]

Tentatively set back to 0.12.

[cboos]

Replying to cboos:

this will require some incompatible API change: propagating the right path information for DELETE changes in Repository.get_changes(), in the same way it's done in Changeset.get_changes().

Well, I couldn't really remember what was that change and why it was needed...

Anyway, restarting with the resync_fix-r5961.diff​ above lead to a solution, which also implies better results for #3778.

Fixed in r9290.