subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: Which is the best tool /process to migrate VSS (with history) to Subversion
Date Mon, 27 Jun 2016 01:33:57 GMT
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.

> 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.

Cheers,

Daniel

Mime
View raw message