New items are already in the map (for deleted + renamed)

Bug #887403 reported by Mike C. Fletcher
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar Subversion Plugin
New
Undecided
Unassigned

Bug Description

On an svn 1.4 server, I am seeing a failure when importing a revision (originally created by bzr-svn) that looks like this:

delete cow/gpg.py
rename client/gpg.py -> cow/gpg.py
revise the renamed file (gpg.py) with numerous refactoring changes

bzr-svn doesn't seem to be able to handle having the renamed edited file replace the deleted file when it goes to re-branch the repository containing the revision.

I have attempted to recreate the situation with a test script (that is, creating a fresh repo with the same pattern), but so far no luck in producing the failure.

Revision history for this message
Mike C. Fletcher (mcfletch) wrote :
Revision history for this message
Mike C. Fletcher (mcfletch) wrote :

I note the diff from the bzr branch that created the revision:

rm bb/gpg.py
mv aa/gpg.py bb/gpg.py
diff of bb/gpg.py

svn 1.4 server's revision diff looks like this:

diff of bb/gpg.py (delta between aa/gpg.py and bb/gpg.py)
diff of aa/gpg.py (deleting all lines)

When I attempt to recreate with a modern svn (1.6.12) repository, the svn diff looks the same, but the bzr/bzr-svn head (or current release) bzr diff looks like this:

mv aa/gpg.py bb/gpg.py
diff bb/gpg.py
rm bb/gpg.py

(note that the order is different, and would seem to be saying that it is deleting the bb/gpg.py file (though the end result is correct)).

With bzr/bzr-svn head pushing into an svn 1.4 server, I get the "you need file revision properties enabled" warning when trying to recreate the issue, but with that enabled the whole process succeeds, so possibly we are no longer producing the confusing file properties, but we still seem to crash if they are already in the repository (even when checking out with head of bzr and bzr-svn).

This is beginning to look like a problem with the file-property-stored revision metadata? Is the traceback trying to tell me that the metadata for the filename bb/gpg.py has already been added to the mapping because we aren't properly handling the duplicate bb/gpg.py file-metadata property set? IIUC what's happening is we're likely pulling the file rev-props out and assuming that the file-path will be unique when we go to add them to the mapping?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.