You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Stefan <lu...@posteo.de> on 2016/07/31 15:55:10 UTC
differences in dump/load/dump cycle
Hi,
I went through a long overdue dump/load cycle of our main repository and
am wondering atm about a difference I see when comparing the dump of the
repository with the original dump.
There are a few (at a guess around 20-50) differences of the following
structure (using fc [olddump] [newdump] on Windows):
***** svn.dump
Node-path: XRebirth/tags/XR v3.53 RC2 (final)/src/SDKs/DX9SDK
Node-kind: dir
Node-action: change
Revision-number: 193958
***** SVN_NEW.DMP
Revision-number: 193958
*****
svn.dump was generated using svnadmin 1.8.15 (32-bit).
The dump was then loaded in a new clean repository using svnadmin 1.8.16
(64-bit). svn_new.dmp was then written using svnadmin 1.8.16 (64-bit) as
well.
The original repository was created using SVN 1.7. At some point in the
past (around 2 years ago) the server was upgraded to SVN 1.8 but the
repository was still kept at fsfs format 5. Around a year later the
repository was upgraded to SVN 1.8 (fsfs format 6).
For the new repository fsfs.conf was modified to enable directory and
property deltification.
For the DX9SDK directory (which is reported being different in both
dumps in some revisions) this was originally using externals and at some
point we switched to a direct copy of the folder (not sure whether
that's relevant though).
Is this difference expected? I remember (and Bert mentioned it too) that
there were some cases for different handling of noop-changes. Is that
what explains the difference I see here? If so, I take it that's
expected and does not result in any difference between the repository
states, or does it? JCorvel, would you have an idea?
Regards,
Stefan
Re: differences in dump/load/dump cycle
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Aug 5, 2016 at 10:06 AM, Vincent Lefevre <vi...@vinc17.net> wrote:
> On 2016-08-03 16:10:16 +0200, Stefan Hett wrote:
>> On 8/3/2016 3:40 PM, Nico Kadel-Garcia wrote:
>> > [export/import instead of dump/load]
> [...]
>> In your export/import approach you would do:
>> export -> import -> export -> compare old vs. new export
>> And like with the dump/load/dump approach above, if you see a difference
>> between the two exports you would then investigate their cause.
>
> export -> import -> export is less safe: how do you know that what
> has been exported is "correct"? Note that with old repositories (and
> perhaps this is still possible with some external tools), starting
> with revision R1 and successively upgrading to R2 may give a different
> result from just getting R2 without intermediate revisions. If the
> problem is unnoticed, information may definitively be lost in the
> repository started from the export.
This seems to work pretty well
diff -r --exclude=.svn \
[directory of old repo checkout] [directory of new repo checkout]
Parsing through the old logs for identical logs is one of the most
time-wasting abuses of manpower I've ever seen in a migration. They
keep being *wrong* from the accumulated history of old bugs.
Leave the old repository around for history if you want, but every few
years, shake the cobwebs off your project and start over from a clean
tag
> Vincent Lefèvre <vi...@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)
Re: differences in dump/load/dump cycle
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2016-08-03 16:10:16 +0200, Stefan Hett wrote:
> On 8/3/2016 3:40 PM, Nico Kadel-Garcia wrote:
> > [export/import instead of dump/load]
[...]
> In your export/import approach you would do:
> export -> import -> export -> compare old vs. new export
> And like with the dump/load/dump approach above, if you see a difference
> between the two exports you would then investigate their cause.
export -> import -> export is less safe: how do you know that what
has been exported is "correct"? Note that with old repositories (and
perhaps this is still possible with some external tools), starting
with revision R1 and successively upgrading to R2 may give a different
result from just getting R2 without intermediate revisions. If the
problem is unnoticed, information may definitively be lost in the
repository started from the export.
--
Vincent Lefvre <vi...@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)
Re: differences in dump/load/dump cycle
Posted by Stefan Hett <st...@egosoft.com>.
On 8/3/2016 3:40 PM, Nico Kadel-Garcia wrote:
> On Wed, Aug 3, 2016 at 9:02 AM, Ryan Schmidt
> <su...@ryandesign.com> wrote:
>> On Aug 3, 2016, at 7:54 AM, Nico Kadel-Garcia wrote:
>>
>>> On Wed, Aug 3, 2016 at 2:16 AM, Ryan Schmidt wrote:
>>>> On Aug 2, 2016, at 9:54 PM, Nico Kadel-Garcia wrote:
>>>>
>>>>> On Tue, Aug 2, 2016 at 7:15 AM, Ivan Zhakov wrote:
>>>>>
>>>>> [dump/load cycles omitted]
>>>>>
>>>>> Please note. This sort of pernicious bug is why I suggest takeing a
>>>>> clean export/import when moving to significantly newer versions, or
>>>>> significantly new project versions, for Subversion repositories. Don't
>>>>> hurt yourself trying to preserve burdensome, possibly flawed history
>>>>> you *do not need*.
>>>> PLEASE STOP.
>>> Sorry, Ryan, but it needed saying.
>> No. I understand you have personal experiences with transferring history that have led you to prefer not to do so, but most of the Subversion developers and other members of this list do not share your views on this matter and I ask you again to refrain from working this opinion into every thread on this mailing list. The one-time existence of a bug in a feature does not mean that one should forever avoid using such a feature even after the bug has been fixed. And just because something like transferring history can be difficult to get right does not mean that the correct answer for everyone is not to try to do so.
> [...]
>
> For new people: I've mentioned doing an svn export/import to a new
> repository, instead of an svnadmin dump/load, as a useful migraiton
> approach on various occasions for years now. It does discard history,
> but it's the cleanest way to dump unwanted content and make a clean
> start with a new layout.
And here is where IMHO the flaw in your argument lies: The assumption
that the data you are discarding is unwanted.
Especially by suggesting new people to discard these information you are
neglecting the fact that especially this user group is likely to have
less experience with versioning systems than you or others would have
and are possibly not in a position to correctly evaluate/realize what
the impact of the discard will be for their particular case/needs.
You are focusing again on "only" losing the history data (which, I
believe I've stated before, is IMHO one (if not THE ONE) most important
data in a version system), while you actually will drop a lot more.
Especially in the scenario you are now suggesting to perform an
export/import process over a dump/load process when >upgrading< from one
to another major subversion version (rather than doing a migration from
one to another CVS).
In this case you will loose all the additional data SVN uses/collected,
not only the history. Mostly I'm referring here to the SVN properties.
Depending on the integration/use of this data, you'd break the
integration in the infrastructure for example.
> It was a potentially useful approach that
> hadn't been mentioned for this thread, and I felt that Stefan (and
> others faced with expensive, potentially dangerous svnadmin dump/load
> cycles) should keep it in mind for their next migration.
Sorry but I can't share your opinion about svnadmin dump/load being
potentially dangerous --- at least not in that this is more dangerous
than a simple export/import with regards to data consistency.
To perform a dump load and then verify the integrity you would do:
dump -> load -> dump -> compare old vs. new dump
If there are differences between the dumps (which really normally
shouldn't be the case) you determine where the difference are coming
from. The mailing list will provide you with the necessary support to
evaluate the impact of the difference you see.
In your export/import approach you would do:
export -> import -> export -> compare old vs. new export
And like with the dump/load/dump approach above, if you see a difference
between the two exports you would then investigate their cause.
Without the final verification step (in both approaches) you certainly
can not be more confident that the process worked flawlessly and you
ended up with what you want.
So once more: I'm sorry, but I really can't even to the slightest share
your believe in that export/import is anywhere
better/easier/more-suitable (in the general case) than a dump/load-cycle.
As said before: there might be very specific cases where this might be
preferable over complete data migration step. But I can't imagine a
single case where this would be preferable over a dump/load/dump cycle.
--
Regards,
Stefan Hett, Developer/Administrator
EGOSOFT GmbH, Heidestrasse 4, 52146 W�rselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Gesch�ftsf�hrer: Bernd Lehahn, Handelsregister Aachen HRB 13473
Re: differences in dump/load/dump cycle
Posted by Vincent Lefevre <vi...@vinc17.net>.
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 Lefvre <vi...@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)
Re: differences in dump/load/dump cycle
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Wed, Aug 3, 2016 at 9:02 AM, Ryan Schmidt
<su...@ryandesign.com> wrote:
>
> On Aug 3, 2016, at 7:54 AM, Nico Kadel-Garcia wrote:
>
>> On Wed, Aug 3, 2016 at 2:16 AM, Ryan Schmidt wrote:
>>>
>>> On Aug 2, 2016, at 9:54 PM, Nico Kadel-Garcia wrote:
>>>
>>>> On Tue, Aug 2, 2016 at 7:15 AM, Ivan Zhakov wrote:
>>>>
>>>> [dump/load cycles omitted]
>>>>
>>>> Please note. This sort of pernicious bug is why I suggest takeing a
>>>> clean export/import when moving to significantly newer versions, or
>>>> significantly new project versions, for Subversion repositories. Don't
>>>> hurt yourself trying to preserve burdensome, possibly flawed history
>>>> you *do not need*.
>>>
>>> PLEASE STOP.
>>
>> Sorry, Ryan, but it needed saying.
>
> No. I understand you have personal experiences with transferring history that have led you to prefer not to do so, but most of the Subversion developers and other members of this list do not share your views on this matter and I ask you again to refrain from working this opinion into every thread on this mailing list. The one-time existence of a bug in a feature does not mean that one should forever avoid using such a feature even after the bug has been fixed. And just because something like transferring history can be difficult to get right does not mean that the correct answer for everyone is not to try to do so.
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. In many cases it can save a great deal of work and should
be considered as one of the first options for complex migrations,
instead of the very last, for reasons I've mentioned before.
For new people: I've mentioned doing an svn export/import to a new
repository, instead of an svnadmin dump/load, as a useful migraiton
approach on various occasions for years now. It does discard history,
but it's the cleanest way to dump unwanted content and make a clean
start with a new layout. It was a potentially useful approach that
hadn't been mentioned for this thread, and I felt that Stefan (and
others faced with expensive, potentially dangerous svnadmin dump/load
cycles) should keep it in mind for their next migration.
Re: differences in dump/load/dump cycle
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 3, 2016, at 7:54 AM, Nico Kadel-Garcia wrote:
> On Wed, Aug 3, 2016 at 2:16 AM, Ryan Schmidt wrote:
>>
>> On Aug 2, 2016, at 9:54 PM, Nico Kadel-Garcia wrote:
>>
>>> On Tue, Aug 2, 2016 at 7:15 AM, Ivan Zhakov wrote:
>>>
>>> [dump/load cycles omitted]
>>>
>>> Please note. This sort of pernicious bug is why I suggest takeing a
>>> clean export/import when moving to significantly newer versions, or
>>> significantly new project versions, for Subversion repositories. Don't
>>> hurt yourself trying to preserve burdensome, possibly flawed history
>>> you *do not need*.
>>
>> PLEASE STOP.
>
> Sorry, Ryan, but it needed saying.
No. I understand you have personal experiences with transferring history that have led you to prefer not to do so, but most of the Subversion developers and other members of this list do not share your views on this matter and I ask you again to refrain from working this opinion into every thread on this mailing list. The one-time existence of a bug in a feature does not mean that one should forever avoid using such a feature even after the bug has been fixed. And just because something like transferring history can be difficult to get right does not mean that the correct answer for everyone is not to try to do so.
Re: differences in dump/load/dump cycle
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Wed, Aug 3, 2016 at 2:16 AM, Ryan Schmidt
<su...@ryandesign.com> wrote:
>
> On Aug 2, 2016, at 9:54 PM, Nico Kadel-Garcia wrote:
>
>> On Tue, Aug 2, 2016 at 7:15 AM, Ivan Zhakov wrote:
>>
>> [dump/load cycles omitted]
>>
>> Please note. This sort of pernicious bug is why I suggest takeing a
>> clean export/import when moving to significantly newer versions, or
>> significantly new project versions, for Subversion repositories. Don't
>> hurt yourself trying to preserve burdensome, possibly flawed history
>> you *do not need*.
>
> PLEASE STOP.
Sorry, Ryan, but it needed saying.
Re: differences in dump/load/dump cycle
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 2, 2016, at 9:54 PM, Nico Kadel-Garcia wrote:
> On Tue, Aug 2, 2016 at 7:15 AM, Ivan Zhakov wrote:
>
> [dump/load cycles omitted]
>
> Please note. This sort of pernicious bug is why I suggest takeing a
> clean export/import when moving to significantly newer versions, or
> significantly new project versions, for Subversion repositories. Don't
> hurt yourself trying to preserve burdensome, possibly flawed history
> you *do not need*.
PLEASE STOP.
Re: differences in dump/load/dump cycle
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Tue, Aug 2, 2016 at 7:15 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
[dump/load cycles omitted]
Please note. This sort of pernicious bug is why I suggest takeing a
clean export/import when moving to significantly newer versions, or
significantly new project versions, for Subversion repositories. Don't
hurt yourself trying to preserve burdensome, possibly flawed history
you *do not need*.
Re: differences in dump/load/dump cycle
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 2 August 2016 at 14:01, Stefan Hett <st...@egosoft.com> wrote:
> On 7/31/2016 11:54 PM, Johan Corveleyn wrote:
>>
>> On Sun, Jul 31, 2016 at 5:55 PM, Stefan <lu...@posteo.de> wrote:
>>>
>>> Hi,
>>>
>>> I went through a long overdue dump/load cycle of our main repository and
>>> am wondering atm about a difference I see when comparing the dump of the
>>> repository with the original dump.
>>>
>>> There are a few (at a guess around 20-50) differences of the following
>>> structure (using fc [olddump] [newdump] on Windows):
>>>
>>> ***** svn.dump
>>>
>>> Node-path: XRebirth/tags/XR v3.53 RC2 (final)/src/SDKs/DX9SDK
>>> Node-kind: dir
>>> Node-action: change
>>>
>>>
>>> Revision-number: 193958
>>> ***** SVN_NEW.DMP
>>>
>>> Revision-number: 193958
>>> *****
>>>
>>>
>>> svn.dump was generated using svnadmin 1.8.15 (32-bit).
>>>
>>> The dump was then loaded in a new clean repository using svnadmin 1.8.16
>>> (64-bit). svn_new.dmp was then written using svnadmin 1.8.16 (64-bit) as
>>> well.
>>>
>>> The original repository was created using SVN 1.7. At some point in the
>>> past (around 2 years ago) the server was upgraded to SVN 1.8 but the
>>> repository was still kept at fsfs format 5. Around a year later the
>>> repository was upgraded to SVN 1.8 (fsfs format 6).
>>>
>>> For the new repository fsfs.conf was modified to enable directory and
>>> property deltification.
>>>
>>> For the DX9SDK directory (which is reported being different in both
>>> dumps in some revisions) this was originally using externals and at some
>>> point we switched to a direct copy of the folder (not sure whether
>>> that's relevant though).
>>>
>>> Is this difference expected? I remember (and Bert mentioned it too) that
>>> there were some cases for different handling of noop-changes. Is that
>>> what explains the difference I see here? If so, I take it that's
>>> expected and does not result in any difference between the repository
>>> states, or does it? JCorvel, would you have an idea?
>>>
>> It's possible that this is a benign change, with no visible effects.
>> I'm not sure.
>>
>> The problem I ran into with dump was a new bug in 1.9.0 (fixed in
>> 1.9.3 I think). It was with no-op changes to files, not directories.
>> This was IMO definitely a bug, because the effect was visible in the
>> new repository (namely, if you ran 'svn log somepath', where somepath
>> was a file which had such a no-op change (not possible to create with
>> the standard svn client btw, but possible with other tools or from a
>> cvs2svn conversion) in revision R, then revision R would not be listed
>> as part of somepath's history). It's unclear to me if you can see a
>> similar loss of "changed-path / history" association.
>>
>> In my case the change in the dumpfile was a bit different: the
>> Node-path / Node-kind / Node-action lines were still there, but the
>> Text-content lines were gone (if you dumped again from the new
>> repository, the entire block with Node-path etc would be gone). See
>> http://svn.haxx.se/dev/archive-2015-09/0269.shtml for the entire
>> (long) discussion, which lead to the bugfix for 1.9.3.
>
> Ah right. Now i recall. Thanks for digging that up. So unless I observe any
> issues, I take it that the change I observed is just a benign one.
>
Just for the records SVN-4598 [1]: No-op changes no longer dumped by
'svnadmin dump' in 1.9
[1] https://issues.apache.org/jira/browse/SVN-4598
--
Ivan Zhakov
Re: differences in dump/load/dump cycle
Posted by Stefan Hett <st...@egosoft.com>.
On 7/31/2016 11:54 PM, Johan Corveleyn wrote:
> On Sun, Jul 31, 2016 at 5:55 PM, Stefan <lu...@posteo.de> wrote:
>> Hi,
>>
>> I went through a long overdue dump/load cycle of our main repository and
>> am wondering atm about a difference I see when comparing the dump of the
>> repository with the original dump.
>>
>> There are a few (at a guess around 20-50) differences of the following
>> structure (using fc [olddump] [newdump] on Windows):
>>
>> ***** svn.dump
>>
>> Node-path: XRebirth/tags/XR v3.53 RC2 (final)/src/SDKs/DX9SDK
>> Node-kind: dir
>> Node-action: change
>>
>>
>> Revision-number: 193958
>> ***** SVN_NEW.DMP
>>
>> Revision-number: 193958
>> *****
>>
>>
>> svn.dump was generated using svnadmin 1.8.15 (32-bit).
>>
>> The dump was then loaded in a new clean repository using svnadmin 1.8.16
>> (64-bit). svn_new.dmp was then written using svnadmin 1.8.16 (64-bit) as
>> well.
>>
>> The original repository was created using SVN 1.7. At some point in the
>> past (around 2 years ago) the server was upgraded to SVN 1.8 but the
>> repository was still kept at fsfs format 5. Around a year later the
>> repository was upgraded to SVN 1.8 (fsfs format 6).
>>
>> For the new repository fsfs.conf was modified to enable directory and
>> property deltification.
>>
>> For the DX9SDK directory (which is reported being different in both
>> dumps in some revisions) this was originally using externals and at some
>> point we switched to a direct copy of the folder (not sure whether
>> that's relevant though).
>>
>> Is this difference expected? I remember (and Bert mentioned it too) that
>> there were some cases for different handling of noop-changes. Is that
>> what explains the difference I see here? If so, I take it that's
>> expected and does not result in any difference between the repository
>> states, or does it? JCorvel, would you have an idea?
>>
> It's possible that this is a benign change, with no visible effects.
> I'm not sure.
>
> The problem I ran into with dump was a new bug in 1.9.0 (fixed in
> 1.9.3 I think). It was with no-op changes to files, not directories.
> This was IMO definitely a bug, because the effect was visible in the
> new repository (namely, if you ran 'svn log somepath', where somepath
> was a file which had such a no-op change (not possible to create with
> the standard svn client btw, but possible with other tools or from a
> cvs2svn conversion) in revision R, then revision R would not be listed
> as part of somepath's history). It's unclear to me if you can see a
> similar loss of "changed-path / history" association.
>
> In my case the change in the dumpfile was a bit different: the
> Node-path / Node-kind / Node-action lines were still there, but the
> Text-content lines were gone (if you dumped again from the new
> repository, the entire block with Node-path etc would be gone). See
> http://svn.haxx.se/dev/archive-2015-09/0269.shtml for the entire
> (long) discussion, which lead to the bugfix for 1.9.3.
Ah right. Now i recall. Thanks for digging that up. So unless I observe
any issues, I take it that the change I observed is just a benign one.
--
Regards,
Stefan Hett
Re: differences in dump/load/dump cycle
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sun, Jul 31, 2016 at 5:55 PM, Stefan <lu...@posteo.de> wrote:
> Hi,
>
> I went through a long overdue dump/load cycle of our main repository and
> am wondering atm about a difference I see when comparing the dump of the
> repository with the original dump.
>
> There are a few (at a guess around 20-50) differences of the following
> structure (using fc [olddump] [newdump] on Windows):
>
> ***** svn.dump
>
> Node-path: XRebirth/tags/XR v3.53 RC2 (final)/src/SDKs/DX9SDK
> Node-kind: dir
> Node-action: change
>
>
> Revision-number: 193958
> ***** SVN_NEW.DMP
>
> Revision-number: 193958
> *****
>
>
> svn.dump was generated using svnadmin 1.8.15 (32-bit).
>
> The dump was then loaded in a new clean repository using svnadmin 1.8.16
> (64-bit). svn_new.dmp was then written using svnadmin 1.8.16 (64-bit) as
> well.
>
> The original repository was created using SVN 1.7. At some point in the
> past (around 2 years ago) the server was upgraded to SVN 1.8 but the
> repository was still kept at fsfs format 5. Around a year later the
> repository was upgraded to SVN 1.8 (fsfs format 6).
>
> For the new repository fsfs.conf was modified to enable directory and
> property deltification.
>
> For the DX9SDK directory (which is reported being different in both
> dumps in some revisions) this was originally using externals and at some
> point we switched to a direct copy of the folder (not sure whether
> that's relevant though).
>
> Is this difference expected? I remember (and Bert mentioned it too) that
> there were some cases for different handling of noop-changes. Is that
> what explains the difference I see here? If so, I take it that's
> expected and does not result in any difference between the repository
> states, or does it? JCorvel, would you have an idea?
>
It's possible that this is a benign change, with no visible effects.
I'm not sure.
The problem I ran into with dump was a new bug in 1.9.0 (fixed in
1.9.3 I think). It was with no-op changes to files, not directories.
This was IMO definitely a bug, because the effect was visible in the
new repository (namely, if you ran 'svn log somepath', where somepath
was a file which had such a no-op change (not possible to create with
the standard svn client btw, but possible with other tools or from a
cvs2svn conversion) in revision R, then revision R would not be listed
as part of somepath's history). It's unclear to me if you can see a
similar loss of "changed-path / history" association.
In my case the change in the dumpfile was a bit different: the
Node-path / Node-kind / Node-action lines were still there, but the
Text-content lines were gone (if you dumped again from the new
repository, the entire block with Node-path etc would be gone). See
http://svn.haxx.se/dev/archive-2015-09/0269.shtml for the entire
(long) discussion, which lead to the bugfix for 1.9.3.
--
Johan