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
