svnadmin load wrongly computes copyfrom-rev

http://subversion.tigris.org/issues/show_bug.cgi?id=1795

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 (wrongly) 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

Max argued that ===
I would argue that this is the correct behaviour. Revisions in dumpfiles
are referred to by numbers, not by their relative positions in the
dumpstream.

I'm resolving this as INVALID - if you would like to discuss the issue,
please post to dev@subversion.tigris.org.

====

I agree that "Revisions in dumpfiles are referred to by numbers, not by
their relative positions in the dumpstream." This is why I said the
current svnadmin load behaves wrongly in case above.

In the case above, the old revision 52 becomes (new) revision 16, and
the old revision 59 becomes (new) revision 21. So svn should figure out
that r21 is copied from r16. However, svn seems to use the relative
position and says r21 is copied from r14.

If you agree with me, I would like to reopen the issue 1795 and append
my last comments.

--Ling

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 18 21:55:50 2004