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

Re: No-op changes no longer dumped by 'svnadmin dump' in 1.9

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Tue, 29 Sep 2015 13:47:49 +0200

On Mon, Sep 28, 2015 at 10:55 AM, Stefan Fuhrmann <
stefan.fuhrmann_at_wandisco.com> wrote:

> On Wed, Sep 23, 2015 at 12:55 PM, Julian Foad <julianfoad_at_btopenworld.com>
> wrote:
>> > Johan Corveleyn wrote:
>> >> [...] stefan2 told me in person that that part of the
>> >> change in r1572363 was unintentional :-). IIUC, he didn't realize that
>> >> it would have this effect on the output of dump.
>> [...]
>> >>>> I think the dump.c part of r1572363 and r1573111 should be reverted /
>> >>>> fixed so that we get the previous behaviour again, and this should be
>> >>>> backported to 1.9. At this point, IMO 'svnadmin dump' is broken in
>> >>>> 1.9.
>> 1. I pretty much agree now that we should revert the change.
> I suggest that we apply the patch below. It is more efficient
> that the original behaviour but ensures that "no-op" changes
> will be retained.

Now that I've read through the whole thread, here my view
on this problem plus an explanation why I think my patch is
the right approach.

First some facts and things that I believe:

* Internally, FSFS can record no-op prop and no-op content
  changes (the delta between new representation and the
  respective proplist / text of its predecessor is empty). There
  is even the possibility of a no-op node change, i.e. a new
  node without touching text nor props (not happening atm).
* SVN versions file trees and the decision how to represent
  them (e.g. as delta) is an implementation detail.
* Relying on implementation details of a lower layer is bad.

* Via FS and Repos layer API, new instances of no-op changes
  to either text and properties can be created.
* Dump files (produced by 3rd party tools or non-incremental
  svnadmin dumps) are another source of those no-op changes.
* SVN editors don't produce no-op changes.

* A commit links user-controlled revision meta data (e.g. comment)
  to a user-controlled list of changes. That link shall not be
  lost when tweak implementation details.
* Dump / load is a compatibility interface between SVN versions
  and allows for forward and backward migration.
* A plain node modification (no text nor prop change) will be
  ignored by "svnadmin load". Even if we changed that on /trunk,
  it would not fix old releases.

From that, we can derive a few requirements:

* If the a revision contains a "M" change, svnadmin must produce
  a dump file that causes previous releases to produce the "M"
  change - within reason.
* Load shall produce no-op changes for the same data as in previous
  releases - within reason. If the FS API would no longer support
  creating no-op changes at some point in the future, the load process
  should issue a warning.
* The dump file contents shall be independent of FS implementation
  details, i.e. use "strict" FS API functions.

No-op changes are rare, hence including them into a dump file
does not significantly increase its size or processing time. The
text / proplist asymmetry in the patch is due to the fact that all
files due have a text but maybe no proplist representation. So,
dumping the text is always safe.

V2 of the patch also covers no-op prop changes to directories.

-- Stefan^2.

Received on 2015-09-29 13:48:13 CEST

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