RE: [PATCH] Issue #4668: Fixing the node key order during svnadmin dump

Michael,

I appreciate everyone's audience on this issue. I have not felt a need to be directly involved in the subversion system mainly because it works so well. This is the first time in 10 years I have felt the need to get directly involved in the SVN development team.

Statement: " As a bug report alone, this one seems pretty easy: Closed/INVALID."

I completely disagree with this statement. I have nearly 300GB of dump files used as a means of backing up my repositories. Some of these dump files are 10 years old. The incremental SVN dump file is automatically generated at each and every commit. After these incremental SVN dump files are created, they are copied and distributed to offsite locations. That way if my server farm crashes, I have a means of assured recovery.

Every month I run sha512sum integrity checks on both the dump files (remotely located in 3 different locations) and the dump file produced by the subversion server. Transferring thousands of 128 byte files is a much better option than transferring thousands of MB dump files over the internet to remote locations. This method and automated scripts have worked for 10 years. I have rebuilt my servers from the original dump files on at least 2 occasions because of computer crashes. This provides me a sanity and validation methodology so that I can spot problems quickly and rebuild before things get out of hand.

Asking me to redistribute 300GB of data to 3 different offsite (and remote) locations, is not a good option.

The SVN dump file has always been presented as the ultimate backup tool of the subversion system. The integrity of the SVN dump file system is of paramount importance. The whole reason why SVN exists in the first place is "data integrity and traceability". The code was changed back in 2015, for better or worse, and we need present solutions to address legacy backups.

Thank-you,

Luke Perkins

-----Original Message-----
From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
Sent: Tuesday, January 24, 2017 09:38
To: Daniel Shahaf <danielsh_at_apache.org>; Julian Foad <julianfoad_at_apache.org>
Cc: lukeperkins_at_epicdgs.us; dev_at_subversion.apache.org
Subject: Re: [PATCH] Issue #4668: Fixing the node key order during svnadmin dump

On 01/24/2017 12:01 PM, Daniel Shahaf wrote:
> The bug is about 1.9 using a different order to 1.8. If we make
> svnadmin use the 1.8 unconditionally, then 1.9 will use a different
> order to 1.10, which essentially recreates the bug for other users.
>
> That is: the option serves to allow admins to choose which of the two
> orders to be consistent with, 1.8 or 1.9.
>
> An alternative to having this option would be a dumpfile comparator
> that ignores header order differences.

As a bug report alone, this one seems pretty easy: Closed/INVALID.
Dumpfile headers were never promised in a particular order, therefore that their order should differ in one version than in another is an interesting factoid, but not actionable *as a defect*. I think it unwise to introduce an option to dictate that new code should try to adhere to an old promise that wasn't.

Now, it's completely reasonable to introduce into the current release a promise regarding future header ordering, though. And it is completely reasonable to backport an enforcement of that ordering (minus its attached promise?) to older releases for the benefit of users that care. And it may very well be that "the 1.8 ordering" is the very ordering you'd settle on, but perhaps not. But to even get here, I think folks have to decide if this is, in fact, a promise that Subversion wants to make. And if so, how universally? Does this order apply to svndumpfilter and svnrdump, too?

In all these scenarios though, nothing can be done about released code save, as you suggest, Daniel, to introduce some external comparator.

-- Mike
Received on 2017-01-24 22:46:06 CET