On Thu, Jun 16, 2016 at 10:51:27AM +0200, Sander Smeenk wrote:
> Trying to do a new checkout of the old repository also results in this error message:
> | % svn co file:///svnroot/foo newcheckout
> | svn: E125012: Invalid character in hex checksum
>
> The issue 'thus' lies in the repository itself. Not the checkout.
>
> Posts found on Google suggested that doing an 'svnadmin dump' with an
> older version of svn, and 'svnadmin load'-ing that on a new svn system,
> essentially recreating the repostory from scratch, helps recover from
> this situation which is indeed true.
Then this is the upgrade path you should follow.
> This is all nice if a repo has a few commits but, as one might
> imagine, a repo from 2006 has a gazillion of commits. The one i'm
> testing with is really small, but i also have a repo that's 28GB on
> disk and i don't really feel like dumping and loading that.
'svnadmin dump/load' is supposed to be faster in 1.9 than it was before.
But I have no first-hand experience with that.
> I fear that running 'svnadmin upgrade' on the repositories will break
> compatibiltiy with older (though not 2006-old) SVN-clients
No, it won't. As long as older clients access the repository over the
network (i.e. not via file:// URLs) there will be no compatibility problem.
> and i don't
> like messing with 'addressing logical' in repository files as i have NO
> idea what this means at all.
See the table here:
http://subversion.apache.org/docs/release-notes/1.9.html#fsfs-improvements
Logical addressing the what the 'Fast access to cold data on disk' row
is all about.
It looks like there could be a bug in the repository upgrade code.
Your repository got new repository format semantics applied to it when
it shouldn't have. Logical addressing only makes sense with packed
repositories which were created as format 7.
Can you run 'svnadmin info' (exists as of 1.9) on the old (non-upgraded)
repository and show the output? That will give us details about its format.
In any case, I would stick with dump/load in your situation instead of
'svnadmin upgrade' which is obviously not working right in your case.
You should rather let the computer spend some time dealing with the dump
and load process, instead of spending your own time working around problems
and not even knowing if the result of your workarounds will be OK.
Received on 2016-06-16 11:20:04 CEST