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.
Received on 2016-05-02 07:19:20 CEST