Re: Corrupt checkout, but 'svn status' and 'svn diff' refuse to admit it?

On Wed, Jul 9, 2025 at 9:53=E2=80=AFPM EML <[email protected]> wrote=
:
>
> I have a 2+ GB repo which I committed to today, to reach rev 357
> I then attempted to use a SQL database in the checkout, which turned out =
to be corrupt. When importing in MariaDB, it complained about a null char i=
n the database
> The database was last committed at r335. I know it hasn't changed since r=
335, and 'svn log' shows r335 as the last commit, two months ago. I have im=
ported the database on several occasions since then, without problems, when=
 building a VM
> I then checked out the entire project at r335 to find out if the database=
 has changed. If I do a standard diff of the database in r357 and r335 they=
 are different. They are the same size, but the r357 version contains binar=
y non-printing data, which is why MariaDB doesn't like it
> After the r357 checkin today, I modified one text file. I deleted this, a=
nd did an 'svn update' at the top level, to get a clean r357
> In the current checkout, 'svn status' shows no modifications. If I run 's=
vn diff -r335 my-database.sql' this reports no differences. So, svn thinks =
the new and old databases are identical, but the plain diff clearly shows t=
hey are different
>  I then did a new complete checkout of the entire project at r357. The da=
tabase in this new checkout is correct - it's identical to the r335 version
> The repo looks good - 'svnadmin dump' doesn't complain, anyway
> db/fs-type says fsfs
> Both the checkout and the repo are on the same machine, using WebDAV, ver=
sion 1.14.1 (r1886195), Ubuntu 22.04
> There are some changes in the .svn directory between the "current" r357 a=
nd the just-checked-out r357
> This is a WordPress database. 'file' reports it as UTF-8 text, and 'wc -L=
' reports a maximum line length of 693319 characters. It doesn't have an sv=
n:mime-type property.
>
> Conclusion: it's possible that a checkout can be corrupted in a way that =
bypasses detection by svn itself. Is this a reasonable conclusion, or have =
I missed something? Is there a maximum line length limit for a "text" file?

[ Moved dev@ to bcc so it is dropped on further replies, and added
users@ to cc. This is at first a question for the users list. ]

If I understand correctly you have one broken working copy in which
the contents of my-database.sql became corrupted somehow (containing
binary data, while it should be UTF-8 text and a valid database). In
the SVN repository that same file is still correct, and a new checkout
at r357 confirms that.

In general, the file in your $broken_workingcopy might have been
changed out-of-band, by some other tool, a virus, a disk failure, ...
but the main question is: why doesn't your $broken_workingcopy detect
that it's modified?

Is that a correct rephrasing of your question?

--=20
Johan