On Sun, Jul 31, 2016 at 5:55 PM, Stefan <[email protected]> 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
