Opened 12 years ago
Closed 12 years ago
#10880 closed defect (worksforme)
"svn move" breaks changeset
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | version control | Version: | 1.0 |
Severity: | normal | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
If the subversion move command is used then changeset throws an error that it can't find the renamed file (by its old name) in the newer revision.
Example:
[In a subversion workspace]
echo blah > test.file svn add test.file svn commit svn move test.file test.file.txt svn commit
[Update the repository]
svn-admin /path/to/trac/proj repository sync MyRepoName
[In Trac repository browser, select "Last Change" link]
Error: No such node No node test.file at revision 16
This was a lot of fun (NOT!) to validate, as I needed to upgrade from 0.12 to 1.0 to verify it was actually still a bug. Only in the process, I came across another bug in the TagsPlugin module that fails on trac-admin … upgrade, which took quiet a while to tracK down (and I thought it had something with sqlite or some other library dependency).
On a side note, might I suggest adding some code to the upgrade() method in trac/env.py to log the participants during the pre-upgrade checks. Something like (and I'm not a python programmer) the lines prepended with '$':
def upgrade(self, backup=False, backup_dest=None): ... irrelevant code removed ... for participant in self.setup_participants: with self.db_query as db: $ self.log.debug("Checking %s.%s for upgrade...", $ participant.__module__, $ participant.__class__.__name__) if participant.environment_needs_upgrade(db): upgraders.append(participant)
Attachments (1)
Change History (5)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
The problem can't be reproduced even with Trac 0.12.2 (svndump attached).
What probably happened was that you tried to look at the file test.file
at revision 2, which indeed doesn't exist at that revision.
About your suggestion for the pre-upgrade checks, what exactly was in the log when you had this issue with the tags plugin, and how would have looked the output with your proposed change?
by , 12 years ago
Attachment: | test-t10880.svndump added |
---|
the given example, with a test.file moved to test.file.txt
follow-up: 4 comment:3 by , 12 years ago
This all started when svndump-ing a delta (from my internal private repository) followed by an 'svnadmin load' (into the public repository, which Trac uses), and running 'trac-admin /trac/path/ repository sync REPO' as usual. In the dump was the result an svn move, which is what cause me to initially notice the error at rev 14 for the changelist (which was the actual subversion HEAD rev).
After this I made a backup copy of my subversion repository and did the svn commands to add the test file and then rename it (as shown in the example) directly to the public repo, followed by a 'trac-admin repository sync', and then a 'trac-admin repository resync'. When I browsed the source again (after the sync, and then after resync) in Trac (rev 16 in svn and Trac) and then clicked on the "Last Change" link, where it produced the same errors.
It seemed reproducible and no matching bug was in the tickets, but I figured it could have been indirectly fixed in 1.0. So I did the upgrade, had fun tracking down the TracPlugins bug, restarted httpd several times along the way (it uses wsgi). Did the "Last Change" again and still got the error (which is what I copied literally into the bug report I submitted at that point).
Since I didn't want those junk revs in my public repository (and to keep it aligned with my private repo), I replaced the test file changed subversion directory with the pre-test backup (back to rev 14). Then I ran 'trac-admin repository sync' to update the cache (which didn't seem to work), and then did the 'trac-admin repository resync' (which did line svn/trac back up) and for some reason magically fixed the initial error. I then immediately posted the ticket comment on how irritating that was, and you know the rest.. [so how frustrating is everyone elses day going? =) ]
comment:4 by , 12 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Replying to chadf@…:
This all started when svndump-ing a delta (from my internal private repository) followed by an 'svnadmin load' (into the public repository, which Trac uses), and running 'trac-admin /trac/path/ repository sync REPO' as usual. In the dump was the result an svn move, which is what cause me to initially notice the error at rev 14 for the changelist (which was the actual subversion HEAD rev).
Sounds like you badly need a DVCS ;-)
This is irritating.. as soon as I rollback my subversion repository back to what it was before I did my "reproduce the bug with a simple example" commits, the error goes away. So was it just a 0.12[.2] bug, and when I did 'trac-admin repository resync' in 1.0 it corrected itself? I remember doing trac-admin repository sync, trac-admin repository resync, and restarting httpd with 0.12.. all with no luck.