Edgewall Software
Modify

Opened 8 years ago

Closed 5 years ago

#4900 closed defect (fixed)

The default svn ChangeCollector information about deleted paths is incomplete

Reported by: cboos Owned by: cboos
Priority: high Milestone: 0.12
Component: version control Version:
Severity: normal Keywords: svn
Cc: trac@…, nick-trac@…
Release Notes:
API Changes:

Description

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.

Attachments (1)

resync_fix-r5961.diff (1.8 KB) - added by cboos 7 years ago.
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 ;-)

Download all attachments as: .zip

Change History (11)

comment:1 Changed 7 years ago by cboos

Another example of this behavior was reported in #5921.

comment:2 Changed 7 years ago by trac@…

  • Cc trac@… added

comment:3 Changed 7 years ago by cboos

  • Milestone changed from 0.12 to 0.10.5

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.

Changed 7 years ago by 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 ;-)

comment:4 follow-up: Changed 7 years ago by cboos

  • Milestone changed from 0.10.5 to 0.12
  • Priority changed from normal to high
  • Severity changed from major to normal

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.

comment:5 follow-up: Changed 7 years ago by anonymous

  • Cc nick-trac@… added

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.

comment:6 in reply to: ↑ 5 Changed 7 years ago by 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.

comment:7 Changed 7 years ago by 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

comment:8 Changed 6 years ago by cboos

  • Milestone changed from 0.13 to 0.12

Tentatively set back to 0.12.

comment:9 Changed 5 years ago by cboos

  • Keywords needmajor added

comment:10 in reply to: ↑ 4 Changed 5 years ago by cboos

  • Keywords needmajor removed
  • Resolution set to fixed
  • Status changed from new to closed

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain cboos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from cboos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.