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

Daniel and team,

I appreciate all the consideration for this issue.

I anticipated that there would be some naming adjustments. If someone has a better naming convention, I am all ears.

My vote is that we implement fixed order for the four keys outlined in the JIRA issue 4668 as soon as possible. The switch would activate the current 1.9 scheme. I am always sensitive to the plight of the system administrator who is tasked with deploying SVN repositories in a real world environment. Thus, maintaining 1.9 formatting option is appropriate.

Regarding the SVN dump comparison tool: I am actively reviewing the options on my own machine. I should have a proposal for a new tool to the development team after I have vetted it with my own servers and networks. I am swamped with other engineering activities so this new tool proposal might be a few weeks out.

Thank-you,

Luke Perkins

-----Original Message-----
From: Daniel Shahaf [mailto:danielsh_at_apache.org]
Sent: Tuesday, January 24, 2017 09:01
To: 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

Julian Foad wrote on Tue, Jan 24, 2017 at 09:51:52 +0000:
> Luke Perkins wrote:
> >I have defined a new switch for svnadmin dump pre-1.8-dump to
> >activate the old node key order. I did my best to try to keep the
> >original authors style. Is this an acceptable switch name?
> >
> >A new parameter to the primary function, svn_repos_dump_fs4 , called
> > svn_boolean_t pre_1_8_dump, . I have search the source code and I
> >think I have all of the function calls covered. Are there any other
> >considerations?
>
> Every new option we add carries new costs with it -- maintenance,
> documentation, user education, more variations to test, etc.
>
> I think there is no significant reason to disable the ordering. Of
> course compatibility is always a concern, and we don't want to fix one
> use case while breaking another. I suppose it could be that the
> supposedly unstable order has actually been coming out stable for some
> people, in which case they would potentially benefit by leaving it is
> as it -- but that's being too "tricky" -- we should keep it simple by not adding an option.
>
> Do you have any particular reason why you think the option is necessary?

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.

> >What is the verification procedure for implementing this change?
>
> Running the regression test suite with the (rather hidden)
> "--dump-load-cross-check" option enabled, plus feedback from yourself
> and one or two others that it "works for you".

I think Luke was asking about whether a unit test is required. I'll leave it to you guys to decide that, but just point out for Luke that svnadmin_tests.py would be where such a test would live.

Cheers,

Daniel
Received on 2017-01-24 23:39:12 CET