[jira] [Commented] (SVN-4668) svnserve dump format order has changed
From: Luke Perkins <lukeperkins_at_epicdgs.us>
Date: Mon, 9 Jan 2017 08:09:41 -0800
From: Luke Perkins [mailto:lukeperkins_at_epicdgs.us]
I think the problem at hand is the following section of code located in libsvn_repos/dump.c starting at line #405. There was a significant rewrite to this section of code back in January of 2015 by a user "julianfoad". Still working on determining root-cause, however, it appears that a directive "Content-length must be last." Is the key-phrase that is reordering the SVN dump records format.
The old format order was:
Now the format order is:
/* Write headers, in arbitrary order.
static const char *revision_headers_order =
/* Write some headers in a given order */
/* Write any and all remaining headers except Content-length.
if (strcmp(key, SVN_REPOS_DUMPFILE_CONTENT_LENGTH) != 0)
/* Content-length must be last */
Bert Huijben commented on SVN-4668:
One of the problems here is that we never explicitly coded dump to be in strict order. The code used to iterate the members of directories in the order they were placed in an APR hashtable. Then at one point APR changed its implementation from mostly stable to randomly changing to avoid attacks in certain usecases of hashtables. The dumpfiles were still valid at this point, but some operations might be in a different order. But all this technically produces 100% the same commits.
When we found this problem in Subversion in operations like 'svn status -U' we changed some parts of our code to start producing a strict stable order, but this new order is different than the one that used to be produced by the old apr hashtable implementation. I'm not sure if the replay api was (already) changed for this.
In Subversion 1.9, as part of optimizing fsfs the filesystem layer can now produce an 'optimal ordering' of members of a directory for cheap access on the filesystem layer... This might have changed the ordering again... and/or... change the ordering again in the future.
Other 1.9 work includes making the svnadmin dump format more stable between the different producers (svnadmin dump, svnrdump dump)
I'll try to add a few interesting issue numbers to this issue. But I think we should discuss this on the users or dev list first before proposing to 'fix' this, as I don't see a simple fix that works for all usecases.
> svnserve dump format order has changed
-- This message was sent by Atlassian JIRA (v6.3.4#6332)Received on 2017-01-10 07:42:35 CET
This is an archived mail posted to the Subversion Users mailing list.