Edgewall Software
Modify

Opened 12 years ago

Closed 12 years ago

#10880 closed defect (worksforme)

"svn move" breaks changeset

Reported by: chadf@… 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)

test-t10880.svndump (1.1 KB ) - added by Christian Boos 12 years ago.
the given example, with a test.file moved to test.file.txt

Download all attachments as: .zip

Change History (5)

comment:1 by chadf@…, 12 years ago

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.

comment:2 by Christian Boos, 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 Christian Boos, 12 years ago

Attachment: test-t10880.svndump added

the given example, with a test.file moved to test.file.txt

comment:3 by chadf@…, 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? =) ]

in reply to:  3 comment:4 by Christian Boos, 12 years ago

Resolution: worksforme
Status: newclosed

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 ;-)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none) 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.