You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Vincent Lefevre <vi...@vinc17.org> on 2005/02/17 23:11:33 UTC
Load/Dump cycle -> different dump files
I did some consistency tests on my repository, but I'm surprised by
the following result. I thought that the dump files of a same format
associated to a repository were necessarily identical, but this is
not the case. Is it normal?
I have a repository from which I generated a first dump file using
"svnadmin dump --incremental". I generated a second dump file using
"svnadmin dump --incremental --deltas", from which I loaded a second
repository with "svnadmin load --force-uuid". From it, I generated a
third dump file using "svnadmin dump --incremental". This third dump
file contains a few differences with the first one.
The differences (I haven't checked all of them) correspond to files
I moved with "svn move". In the copy part, lines like the following
ones are removed:
< Prop-content-length: 40
< Content-length: 40
<
< K 12
< svn:keywords
< V 7
< Id Date
< PROPS-END
This doesn't seem to be a problem since these keywords had already
been defined in the source revision. But I wonder if this behavior
is expected.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Load/Dump cycle -> different dump files
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2005-02-27 at 22:39, Vincent Lefevre wrote:
> If I understand the problem, in the past, "svn move" readded existing
> properties to the repository. When using "svnadmin dump --incremental"
> (without --deltas) on such a repository, these readded properties
> appear in the dump file.
Note that "svnadmin dump --incrementals" includes all property values on
a node with any modified properties, even if only some of the properties
have changed.
> But when using the --deltas option (on the
> same repository), one has a "Prop-delta: true" header and the delta
> on the properties is empty, since the properties keep the same value.
> But this is ambiguous: does this mean that some properties have been
> set to the same values or does this mean that these properties haven't
> been changed? Though this means the same thing, the representation in
> the repository isn't the same.
I don't think the representation in the repository is really important.
(Similarly, I don't think the differences in the dump files are
important, since they have the same meaning.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Load/Dump cycle -> different dump files
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-02-22 12:15:30 -0600, C. Michael Pilato wrote:
> This behavior is not expected (at least, not by me). Could you
> distill this into a tiny reproduction recipe and file this as an
> issue for exploration in our public issue tracker? If you can't,
> please let me/us know so someone else can try to pick this up.
Well, it seems that the problem can't be reproduced with recent
versions of Subversion, except by writing a dump file manually
or generating a dump file from a repository created with an old
Subversion.
If I understand the problem, in the past, "svn move" readded existing
properties to the repository. When using "svnadmin dump --incremental"
(without --deltas) on such a repository, these readded properties
appear in the dump file. But when using the --deltas option (on the
same repository), one has a "Prop-delta: true" header and the delta
on the properties is empty, since the properties keep the same value.
But this is ambiguous: does this mean that some properties have been
set to the same values or does this mean that these properties haven't
been changed? Though this means the same thing, the representation in
the repository isn't the same.
With my old example, the diff starts with:
--- dump.0 2005-02-17 23:43:27.000000000 +0100
+++ dump.1 2005-02-17 23:43:37.000000000 +0100
@@ -1,4 +1,4 @@
-SVN-fs-dump-format-version: 2
+SVN-fs-dump-format-version: 3
UUID: 99759db8-4ec0-0310-8bf9-df86780d22d8
@@ -43,13 +43,10 @@
Node-action: add
Node-copyfrom-rev: 56
Node-copyfrom-path: config/debian/local.ay/XF86Config-4
-Prop-content-length: 40
-Content-length: 40
+Prop-delta: true
+Prop-content-length: 10
+Content-length: 10
-K 12
-svn:keywords
-V 7
-Id Date
PROPS-END
[...]
I've attached a dump file (dump1), based on the old Subversion
behavior after a "svn move". Here's what I did:
ay:~> svnadmin create --fs-type fsfs svntest1
ay:~> svnadmin load --force-uuid svntest1 < dump1
ay:~> svnadmin dump --incremental svntest1 > dump2
ay:~> svnadmin dump --incremental --deltas svntest1 > dump3
ay:~> svnadmin create --fs-type fsfs svntest3
ay:~> svnadmin load --force-uuid svntest3 < dump3
ay:~> svnadmin dump --incremental svntest3 > dump4
ay:~> svnadmin dump --incremental --deltas svntest3 > dump5
dump1 and dump2 contain:
----------------------------------------
Node-path: bar
Node-kind: file
Node-action: add
Node-copyfrom-rev: 1
Node-copyfrom-path: foo
Prop-content-length: 40
Content-length: 40
K 12
svn:keywords
V 7
Id Date
PROPS-END
----------------------------------------
dump3 contains:
----------------------------------------
Node-path: bar
Node-kind: file
Node-action: add
Node-copyfrom-rev: 1
Node-copyfrom-path: foo
Prop-delta: true
Prop-content-length: 10
Content-length: 10
PROPS-END
----------------------------------------
dump4 and dump5 contain:
----------------------------------------
Node-path: bar
Node-kind: file
Node-action: add
Node-copyfrom-rev: 1
Node-copyfrom-path: foo
----------------------------------------
So, should Subversion care about the old behavior?
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Re: Load/Dump cycle -> different dump files
Posted by "C. Michael Pilato" <cm...@collab.net>.
This behavior is not expected (at least, not by me). Could you
distill this into a tiny reproduction recipe and file this as an issue
for exploration in our public issue tracker? If you can't, please let
me/us know so someone else can try to pick this up.
Vincent Lefevre <vi...@vinc17.org> writes:
> I did some consistency tests on my repository, but I'm surprised by
> the following result. I thought that the dump files of a same format
> associated to a repository were necessarily identical, but this is
> not the case. Is it normal?
>
> I have a repository from which I generated a first dump file using
> "svnadmin dump --incremental". I generated a second dump file using
> "svnadmin dump --incremental --deltas", from which I loaded a second
> repository with "svnadmin load --force-uuid". From it, I generated a
> third dump file using "svnadmin dump --incremental". This third dump
> file contains a few differences with the first one.
>
> The differences (I haven't checked all of them) correspond to files
> I moved with "svn move". In the copy part, lines like the following
> ones are removed:
>
> < Prop-content-length: 40
> < Content-length: 40
> <
> < K 12
> < svn:keywords
> < V 7
> < Id Date
> < PROPS-END
>
> This doesn't seem to be a problem since these keywords had already
> been defined in the source revision. But I wonder if this behavior
> is expected.
>
> --
> Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
> Work: CR INRIA - computer arithmetic / SPACES project at LORIA
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org