branchcreator.py:720: ValueError: list.remove(x): x not in list

Bug #407256 reported by Václav Šmilauer
38
This bug affects 7 people
Affects Status Importance Assigned to Milestone
svn2bzr
Confirmed
Undecided
Unassigned

Bug Description

When coverting quite large svn repository, I get the following traceback (bzr 1.17-1, svn2bzr current trunk):

Traceback (most recent call last):
  File "svn2bzr/svn2bzr.py", line 194, in <module>
    main()
  File "svn2bzr/svn2bzr.py", line 187, in main
    log=log)
  File "svn2bzr/svn2bzr.py", line 88, in svn2bzr
    creator.run()
  File "/tmp/svn2bzr/branchcreator.py", line 622, in run
    entries = self.filter_entries(entries)
  File "/tmp/svn2bzr/branchcreator.py", line 671, in filter_entries
    entries = self.filter_moves(entries)
  File "/tmp/svn2bzr/branchcreator.py", line 720, in filter_moves
    entries.remove(de) # rem perfectly matching del entry
ValueError: list.remove(x): x not in list

If you want to try, nightly svn dump is available at http://download.berlios.de/svndumps/yade-repos.gz (32MB). It happens just after "Commited revision 101".

Curiously, IIRC, converting the dump did work a few weeks back; however, svn2bzr trunk didn't change since then, and the SVN was at rev. 101 a few years back (now at 1905).

I will be glad to provide more information if you need.

Kees Cook (kees)
Changed in svn2bzr:
status: New → Confirmed
Revision history for this message
David Owen (dsowen) wrote :

I believe this is triggered by a dump representing some file being copied twice, then deleted. While processing, the delete is matched up with the first copy to produce a rename, leaving the second copy unmatched.

Revision history for this message
David Owen (dsowen) wrote :
Revision history for this message
David Owen (dsowen) wrote :
Revision history for this message
Eric Wald (eswald) wrote :

Also happens when the second copy and the delete are merged into a single move command.

Wrapping the single offending line in try...except causes another problem: Only one of the copies makes it into the commit. That problem is fixed by moving the node-action mangling into the else clause.

Revision history for this message
Arnd (arnd-arndnet) wrote :

@eswald:

your patch changes lines around 730 (fcopies) while the error message quoted is in line 720 (dcopies)

Revision history for this message
Eric Wald (eswald) wrote :

@Arnd:

Good catch. The patch fixed my issue, which must have been a slightly different case. I'm guessing the same logic would fix the dcopies case, given the nearly identical code, but could use extra testing.

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.