On Tue, Apr 28, 2015 at 6:18 PM, Roderich Schupp <roderich.schupp_at_gmail.com>
wrote:
> Hi,
>
> found in the wild, reproducible with this script:
>
Hi Roderich,
Thanks for the report & reproduction recipe.
I'll have a look at it over the next few days
(currently travelling with a few hours to spare)
and I already have a suspicion.
I also assume that whatever the problem is
will also affect files that were initially committed
as empty (or with some very short contents)
in format 1 or 2 repositories that had no
deltification support at all.
>
> --------------
> # cleanup previous experiments
> rm -rf repo import
>
> url=file://$PWD/repo
> svnadmin create --compatible-version 1.8 repo
> cat > repo/db/fsfs.conf <<EOF
> [deltification]
> enable-dir-deltification=true
> max-deltification-walk=63
> [rep-sharing]
> enable-rep-sharing=false
> EOF
>
> echo "# import..."
> mkdir import
> (
> cd import
> echo foo > foo.txt
> echo bar > bar.txt
> mkdir -p directory-with-a-longish-name
> svn import -m "initial import" $url
> )
> toplevel=$(svn ls $url | sed "s|^|$url/|")
>
> echo "# delete everything"
> svn delete -m "delete everything" $toplevel
>
> echo "# list empty repo"
> svn ls $url && echo "# OK (nothing here to see)"
> --------------
>
> and its output (tested with Subversion 1.8.10, .11 and .13):
>
> # import...
> Adding bar.txt
> Adding directory-with-a-longish-name
> Adding foo.txt
>
> Committed revision 1.
> # delete everything
>
> Committed revision 2.
> # list empty repo
> svn: E070014: Can't read file '/work/repo/db/revs/0/0': End of file found
>
The root folder of r2 deltifies against the empty root
of r0 which is PLAIN and not a DELTA rep. Should
still work but maybe there is something other "special"
about the r0 contents.
Notes:
> - "svnadmin verify" does NOT report any errors
>
Since it is the root folder that has this issue, some
tests might simply not be applied to it. Still likely a
bug - depending on whether the repo is actually
corrupt.
> - indeed the output of "svnadmin dump" looks correct
>
Directory contents is not part of the dump file -
it is implied by adding / modifying / deleting nodes.
So, this is not a surprise.
> - enable-dir-deltification is definitely required to hit the bug
> - also the length of the name of the directory seems to matter,
> at least ~12 characters are required
>
The latter makes sense since there are cut-off
points below which there will be no deltification.
Adding a 4th node in r1 should have the same
effect as a long file name.
Also, my guess is that the reproduction does not
require a subdir but would be fine with just file
nodes.
> The above script produces no error for Subversion 1.9.0 beta1, so FWIIW
> I ran svn-bisect on trunk from the branching-off point for 1.8.x ("good",
> ie. has the bug)
> to the branching-off point of 1.9.x ("bad", ie. it's fixed) and the
> "culprit" came out
> as r1554942 which supposedly isn't a fix at all (and modifies a file that
> doesn't exist in 1.8.x).
>
It effects the application of the deltification and
adds a few more "hurdles". It may prevent the
problem entirely (no delta against small reps)
or merely raise the bar, meaning that r1 needs
to be much bigger.
I'll keep you posted.
-- Stefan^2.
Received on 2015-04-29 04:40:30 CEST