On 2 August 2016 at 14:01, Stefan Hett <ste...@egosoft.com> wrote: > On 7/31/2016 11:54 PM, Johan Corveleyn wrote: >> >> On Sun, Jul 31, 2016 at 5:55 PM, Stefan <luke1...@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
