On 6/26/2016 05:48, Nico Kadel-Garcia wrote:
> On Sat, Jun 25, 2016 at 8:24 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>>> Last: one of the most pernicious sources of bugs in Subversion's
>>> history, one that I've encountered personally, has been the upgrade
>>> process between releases of Subversion for the repository itself If
>>> you don't need to have the dataqbase and fileysstem baggage of a full
>>> history, then the bugs of upgrading become much more avoidable.
>> Can you be more specific? What bug has broken your repository during
>> upgrade? Were you careful enough yourself, as an administrator, while
>> performing such a critical operation to the "crown jewels" of some
>> developer team?
> This one.
>
> 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.
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).
Regards,
Stefan
Received on 2016-06-26 22:28:39 CEST