On 30.04.2016 02:47, Daniel Shahaf wrote:
Stefan Fuhrmann wrote on Fri, Apr 29, 2016 at 09:29:20 +0200:
Issue #4554 talks about two things, a set of conditions and their
immediate impact (broken dump file). The dump file will simply
not load and that's easy enough to detect. The set of conditions
is as follows:
1. Representation sharing must be enabled (default since 1.6 or so).
2. At least one change must be committed using a 1.8+ server.
3. Property and directory deltification must not be enabled
(available since 1.8 but enabled by default only since 1.9).
4. A file gets committed whose contents happens to look exactly
like a serialized hash (i.e. a directory content or property list)
that has been committed with 1.8+.
5. No file with the same contents has been committed using a pre-1.8
server with rep-sharing enabled.
Point 4 is unlikely to occur by accident. By far your best shot
at this is to have a 4-byte file containing "END\n", which happens
to match an empty hash. Another chance is committing the contents
of a .svn folders of a pre-1.7 working copy - which requires some
serious fiddling with the .svn folders.
If these conditions do occur in a repository, though, a third-party tool
that does not verify checksums for empty files would incur data loss
when accessing that repository through Subversion 1.9.3 or older.
There are two types of interfaces here: Some SVN API
and the dump file. Both are affected. Invalid dump
files are easy to identify while API users would expect
file_length() to return correct results without double-
checking them, which it did not.
Does any third-party tool make that optimization?
Such a tool would probably ignore checksums altogether
because there is no point in explicitly ignoring them
for empty files only.
'svnadmin load' will fail.
This sentence applies to any version of svnadmin, including pre-1.9.3
ones.
Correct.
No-op changes cannot be produced by standard SVN tooling
They can: just undo the changes while 'commit --editor-cmd' is waiting
for the editor to exit. (I posted a scripted version of that at some
point, but can't find it.)
Thanks for pointing that out. I was not aware that this
would send the change list before waiting for commit msg.
-- Stefan^2.
