On 2016-08-03 09:40:59 -0400, Nico Kadel-Garcia wrote:
> I don't insist on it: it's not always the correct answer. But it's not
> the only time dump/load has suffered from bugs, and I'm sure it won't
> be the last.
Yes, there have been several issues in the past, but people care
about these issues mainly because they care about the history.
Even if one occasionally wants to start a new repository, this
should not be dictated by an upgrade of Subversion. And what about
the old repository? I think that in such a case, one wants to
archive it, but one also needs to make sure that it is still
correctly readable with new Subversion versions and not be affected
by new bugs.
FYI, I regularly do partial or full dumps of my repositories (always
a full dump after a major Subversion upgrade), and compare the result
with the old dump. If I need a dump/load cycle, then I also always do
a full dump after that to compare.
I've found differences many times after a major upgrade, and I've
reported potential issues in the dev list. Sometimes, these were
non-significant changes: reordering of data (the most annoying one
was the random order after some APR upgrade because it broke the
comparisons, but then a new fixed order was chosen in Subversion),
blank lines, redundant information dropped, additional hashes...
Sometimes, these were bugs. But as long as one keeps the old dumps
until the problem is solved, one doesn't lose anything.
BTW, I would say that if there is a difference between dumps that
is not a bug, then do a load/dump again to make sure that the dump
is loadable and identical to the dump obtained after this operation.
There are sometimes differences in the compressed deltas, but I
suppose that if the hashes are the same, then everything is OK.
I suppose that Subversion always checks all the hashes when doing
a load.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Received on 2016-08-05 15:54:04 CEST