Opened 18 years ago
Closed 15 years ago
#4900 closed defect (fixed)
The default svn ChangeCollector information about deleted paths is incomplete
Reported by: | Christian Boos | Owned by: | Christian Boos |
---|---|---|---|
Priority: | high | Milestone: | 0.12 |
Component: | version control | Version: | |
Severity: | normal | Keywords: | svn |
Cc: | trac@…, nick-trac@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal 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)
Change History (11)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
Cc: | added |
---|
comment:3 by , 17 years ago
Milestone: | 0.12 → 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.
by , 17 years ago
Attachment: | resync_fix-r5961.diff added |
---|
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 ;-)
follow-up: 10 comment:4 by , 17 years ago
Milestone: | 0.10.5 → 0.12 |
---|---|
Priority: | normal → high |
Severity: | major → 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.
follow-up: 6 comment:5 by , 17 years ago
Cc: | 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 by , 17 years ago
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 by , 17 years ago
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:9 by , 15 years ago
Keywords: | needmajor added |
---|
comment:10 by , 15 years ago
Keywords: | needmajor removed |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Replying to cboos:
this will require some incompatible API change: propagating the right
path
information forDELETE
changes inRepository.get_changes()
, in the same way it's done inChangeset.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.
Another example of this behavior was reported in #5921.