[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1.9.4 fix

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sat, 30 Apr 2016 00:47:05 +0000

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.