Critical Description
As I learned somewhere (I don't remember), svnadmin load can take dump files with non-consecutive revision numbers. The non-consecutiveness can be caused by, say, manually modification of the dump file, or some dump filter. However, when computing the copyfrom-rev, svnadmin sometimes makes mistakes. I have a real-world case but it might be too big to upload here. Before I make a toy example for this bug report, here is the situation that the mistake might happen: Revision 59: copyfrom-rev: 52 Even if some revisions between 52 and 59 (say, r54 & r55) have been removed from the dump file, the svnadmin still uses the relative distance (this case, 59-52=7) for the load operation. Thus svnadmin generates something like Revision: 21 copyfrom-rev: 14 Instead of the correct one: Revision: 21 copyfrom-rev: 16
Original issue reported by ling