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
If you 'svnadmin dump' it with 1.9, you'll see:
In fact, Julian already observed this as a difference between
'svnadmin dump' and 'svnrdump dump', in . 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 , 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.
Received on 2015-09-21 16:38:59 CEST