Re: differences in dump/load/dump cycle
On 7/31/2016 11:54 PM, Johan Corveleyn wrote: On Sun, Jul 31, 2016 at 5:55 PM, Stefan 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
On 2 August 2016 at 14:01, Stefan Hett wrote: > On 7/31/2016 11:54 PM, Johan Corveleyn wrote: >> >> On Sun, Jul 31, 2016 at 5:55 PM, Stefan 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
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*.
Re: differences in dump/load/dump cycle
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.
