svnadmin load wrongly computes copyfrom-rev

[Ling Li <li...@caltech.edu>]

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

Re: svnadmin load wrongly computes copyfrom-rev

[Max Bowsher <ma...@ukf.net>]

Ling Li wrote:
> 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

I did some tests and realized that I'd misunderstood you. You are entirely
correct, there is a bug here.
Issue reopened.

Max.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org