On Wed, Sep 23, 2015 at 12:55 PM, Julian Foad <julianf...@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.
-- Stefan^2.
Index: dump.c
===================================================================
--- subversion/libsvn_repos/dump.c (revision 1703916)
+++ subversion/libsvn_repos/dump.c (working copy)
@@ -1168,9 +1168,20 @@
compare_root, compare_path,
eb->fs_root, path, pool));
if (kind == svn_node_file)
- SVN_ERR(svn_fs_contents_different(&must_dump_text,
- compare_root, compare_path,
- eb->fs_root, path, pool));
+ {
+ /* No-op changes are entirely legal. To cause 'svnadmin load' to
+ * re-create the node change, we must either include a prop or a
+ * text change (or both). Even if those end up to not change the
+ * contents, this will trigger the creation of the noderev itself
+ * and the respective changed paths list entry. */
+ if (must_dump_props)
+ SVN_ERR(svn_fs_contents_different(&must_dump_text,
+ compare_root, compare_path,
+ eb->fs_root, path, pool));
+ else
+ must_dump_text = TRUE;
+ }
+
break;
case svn_node_action_delete:
