On Thu, Dec 14, 2017 at 9:01 AM, Andreas Mohr <andi_at_lisas.de> wrote:
> On Wed, Dec 13, 2017 at 05:19:50PM -0500, Nico Kadel-Garcia wrote:
>> On Wed, Dec 13, 2017 at 2:27 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>> > Step 1 is very safe and easy and you are unlikely to encounter problems.
>> > Step 2 is more of an unknown. There are various bugs that existed in older
>> > versions that allowed some data to be stored in repository in format that
>> > was in violation of what was intended. Newer versions of Subversion detect
>> > and enforce those rules better. If you have any of this data you might get
>> > errors when loading the repository to the new format. If you do, you can
>> > search the archives of this list to find answers on how to proceed.
>>
>> Jumping that far between versions, I'd *expect* trouble. The
>> repository is basically a file-system based database. I'd urge *not*
>> updating that in place.
>
> Are we talking:
> - full update, with certain suitable (last-minor stable) interim versions used?
> - full update, going from earth to mars?
>
> Possibly you're recommending "avoiding *both* variants of such a large jump,
> if possible".
>
>
> If this "problematic" sentiment holds, then interesting questions are:
> - is an upgrade from very old versions generally supposed to be "doable"?
> (i.e., should this use case be supported as best as can be?)
> - if support ought to be best/improved, then how to analyze whether this
> holds water? (in this particular case)
> Would perhaps be good to go through such an upgrade for test purposes only,
> then "play a bit" with the resulting test-only data
> to possibly determine some issues.
I want to state clearly here that such an upgrade should work, and is
definitely supported. In gerenal, Subversion has very good
compatiblity and upgradeability guarantees. I'd expect no trouble,
even going from 1.0 to 1.9, but maybe that's just me ...
Of course, no software is free of bugs, so a good sysadmin is always
cautious when fiddling with important data such as the version control
backend (i.e. make a backup, or work on a copy of the original). But
I've never seen 'svnadmin upgrade' corrupt an svn database (note:
'svnadmin upgrade' does not rewrite the entire database, it only
adjusts the format so your new server binaries can start using new
features for newly created revisions).
Dumping and loading to rewrite your backend database into the latest
format is a bit more work, and there are a couple of hairy parts. But
those are quite well known (most notably, the fact that from SVN 1.6
onwards the backend enforced LF line-termination for properties,
without offering an option to normalize them with 'svnadmin load' --
OTOH svnsync has that option). I suggest going though the dump+load
faq entry [1] when you want to go that way (which also points to a
specific faq entry about the LF-error [2]).
Relatedly: soon SVN 1.10 will be released (the release train has
started for an RC1), which adds a --normalize-props option to
'svnadmin load' [3]. That should make this much easier.
[1] http://subversion.apache.org/faq.html#dumpload
[2] http://subversion.apache.org/faq.html#fix-nonLF-log
[3] http://svn.apache.org/viewvc?view=revision&revision=1807836
--
Johan
Received on 2017-12-14 09:53:02 CET