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.
Does any third-party tool make that optimization?
> 'svnadmin load' will fail.
This sentence applies to any version of svnadmin, including pre-1.9.3
ones.
> 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.)
Cheers,
Daniel
Received on 2016-04-30 02:47:07 CEST