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

Re: differences in dump/load/dump cycle

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Sun, 31 Jul 2016 23:54:27 +0200

On Sun, Jul 31, 2016 at 5:55 PM, Stefan <luke1410_at_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.

-- 
Johan
Received on 2016-07-31 23:55:05 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.