On 6/27/2016 03:33, Daniel Shahaf wrote:
> Stefan wrote on Sun, Jun 26, 2016 at 22:28:20 +0200:
>> On 6/26/2016 05:48, Nico Kadel-Garcia wrote:
>>> http://stackoverflow.com/questions/10279222/how-can-i-fix-the-svn-import-line-endings-error
>> I remember the old discussions relating to this issue only very faintly,
>> but the same thread suggests the issue was "resolved" in SVN 1.7 and if
>> I'm not mistaken this was done by adding the --bypass-prop-validation
>> command line option to svnadmin load.
>>
>> I've been around for quite some time in SVN and did a lot of repository
>> upgrades myself and while there were certainly issues with the upgrade
>> process due to some specific edge cases, side effects of other problems,
>> or even issues in the upgrade code, issues during an upgrade process are
>> really everything else but common. So while that particular problem it
>> wasn't resolved on the 1.6 branch, it got resolved on 1.7.x+.
>>
>> One might question the way version releases go in SVN and the lack of a
>> more stable long term ESR release, but at some point you have to just
>> make a call based on available resources. There's only a limited amount
>> of manpower available and you have to decide what to focus on.
> The reason --bypass-prop-validation wasn't backported to 1.6.x has
> nothing to do with manpower. Adding a --option flag is an API change so
> may not be done in a patch release, only in a minor release.
>
> Ideally we would have discovered the problem during the 1.6.0
> alpha/beta/rc phase, then we could have added the option flag before the
> 1.6.0 release.
I should have made it stand out more clearly that I didn't suggest that
this particular case was related to the statement of limited manpower.
The statement about limited resources is merely my personal conclusion
why only the current version receives bugfixes and why there's only one
previous old stable version which receives security/data corruption
fixes (I haven't heard that statement directly from any SVN developer,
but I always took it for the being the logical reason --- I might stand
corrected though).
>
>> SVN is a really stable product, even with (or actually maybe because of)
>> the policy of only supporting the current and the previous release (and
>> for the previous release only backport security and data corruption fixes).
>> While the downside of this is that in some cases bugs won't be resolved
>> in previous releases anymore, it also helps to improve the stability of
>> the old-stable versions (since only absolutely vital code changes get in
>> and therefore you reduce the risk of adding new issues).
> I always thought the "only security and data corruption" rule was
> a lower bound but not an upper bound; that is: other bugfixes are also
> eligible to be nominated and backported, even if in practice few
> non-critical bugfixes garner three +1 votes in the older minor line's
> STATUS file.
Well, if it is like this, then I might have gotten a false impression.
That said, thanks for the clarification of how you understand the
statement. I'll certainly take that into account and might propose
bugfixes for non-security/-data-loss issues in the future, if I feel
strongly enough about them.
Rergards,
Stefan
Received on 2016-06-27 08:01:29 CEST