[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

differences in dump/load/dump cycle

From: Stefan <luke1410_at_posteo.de>
Date: Sun, 31 Jul 2016 17:55:10 +0200

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?

Regards,
Stefan

Received on 2016-07-31 17:55:30 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.