[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Which is the best tool /process to migrate VSS (with history) to Subversion

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Mon, 27 Jun 2016 01:33:57 +0000

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
Received on 2016-06-27 03:34:18 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.