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

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

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Mon, 21 Sep 2015 16:38:20 +0200

Behaviour of 'svnadmin dump' has changed in 1.9: a no-op change to
path X comes into the dump file without "Text-content" block (there is
still a "Node-action: change" to the path X). The consequence is that
the no-op change disappears when you load this into a new repository.
When you dump from the new repository again, the node-change is
completely gone from the revision.

For an example, run svnmucc_tests.py 2 'basic svnmucc tests' without
cleanup. The test repository contains a no-op modification to an empty
file, in revision 16.

If you 'svnadmin dump' this revision with 1.8 (you'll have to run the
svnmucc test with 1.8, otherwise you'll not be able to dump it), it

Node-path: boozle/buz/svnmucc-test.py
Node-kind: file
Node-action: change
Text-content-length: 0
Text-content-md5: d41d8cd98f00b204e9800998ecf8427e
Text-content-sha1: da39a3ee5e6b4b0d3255bfef95601890afd80709
Content-length: 0

If you 'svnadmin dump' it with 1.9, you'll see:

Node-path: boozle/buz/svnmucc-test.py
Node-kind: file
Node-action: change

In fact, Julian already observed this as a difference between
'svnadmin dump' and 'svnrdump dump', in [1]. He didn't realize that
this was a behaviour change in 'svnadmin dump' ... if he would have
done the same test with 1.8, he wouldn't have seen a difference
between dump and svnrdump.

The change was introduced in r1572363 and further tweaked in r1573111,
by stefan2. When discussing this last week in Berlin, Stefan agreed
that this was most likely an unintended / unwanted change.

As already discussed by others on the mailinglist [2], I think it's
important that dump and load try to preserve repository data as much
as possible (except for necessary fixes, normalizations, ...). In this
case, information is being lost, and the newly loaded repository is
visibly different from the original (see below). I think this should
be fixed in 'svnadmin dump'.

For now, I will probably use 1.8 to perform the dump that I want to load in 1.9.

To illustrate a visible difference:
- 'svn log path/with/no-op/change/in/rev/R' will show rev R.
- the same command will no longer show rev R after a dump/load with 1.9.

In our repository, there are a couple of such revisions, dating from
our conversion from cvs to svn (actually, revision N-1 contains a real
change, but only a short log message; and revision N has a no-op
change to that same path, and a very informative log message
describing the real change in detail). It's not like we consciously
used this as a specific use-case, but now the information is like that
in our repository, and I'd hate to lose it.

[1] https://mail-archives.apache.org/mod_mbox/subversion-dev/201501.mbox/%3C1421067283.19093.YahooMailNeo@web87701.mail.ir2.yahoo.com%3E

[2] https://mail-archives.apache.org/mod_mbox/subversion-dev/201412.mbox/%3C1418991791.49595.YahooMailNeo@web87702.mail.ir2.yahoo.com%3E

Received on 2015-09-21 16:38:59 CEST

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