Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <5726E366.1090803@apache.org>
Date: Mon, 02 May 2016 07:19:34 +0200
From: Stefan Fuhrmann <stefan2@apache.org>
Organization: Apache Software Foundation
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Daniel Shahaf <d.s@daniel.shahaf.name>
CC: Johan Corveleyn <jcorvel@gmail.com>,
 Terry Dooher <Terry.Dooher@naturalmotion.com>,
 users@subversion.apache.org
Subject: Re: 1.9.4 fix
References: <c51abb3f340e424888e8b3c11841a04e@OXEXC2.NM.local> <CAB84uBU-RNHHXVMAazzu7CEJGzy=wqdEnB04NorAC=GqzcMXTQ@mail.gmail.com> <57230D50.6000100@apache.org> <20160430004705.GA20016@tarsus.local2>
In-Reply-To: <20160430004705.GA20016@tarsus.local2>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Mon, 02 May 2016 05:19:20 -0000

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.