On 2 August 2016 at 14:01, Stefan Hett <stefan_at_egosoft.com> wrote:
> On 7/31/2016 11:54 PM, Johan Corveleyn wrote:
>>
>> On Sun, Jul 31, 2016 at 5:55 PM, Stefan <luke1410_at_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
Received on 2016-08-02 13:16:16 CEST