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.
--
Regards,
Stefan Hett
