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 2008/09/30 11:24:17 UTC
Re: Bug: "svnadmin dump --incremental --deltas" gives too much
output
I can reproduce this problem on the MPFR repository (revision 5629).
So, if someone needs a testcase, this is possible (but quite large).
FYI, this happens on updates of ChangeLog files.
For the MPFR case:
svn diff -> 222778 bytes
svnadmin dump --incremental --deltas (version 1.1.4) -> 311751 bytes
svnadmin dump --incremental --deltas (version 1.5.1) -> 988544 bytes
The dump with 1.1.4 was obtained on the MPFR svn server itself.
The dump with 1.5.1 was obtained on a different machine, after
rebuilding a repository from the full dump.
--
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 / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Bug: "svnadmin dump --incremental --deltas" gives too much output
Posted by Paul Charlton <te...@byiq.com>.
The code is definitely inconsistent with the various documentation. A quick look at "dump.c" in "lib_svnrepos" shows the following logic:
(dump.c)
/* Fetch the editor which dumps nodes to a file. Regardless of
what we've been told, don't use deltas for the first rev of a
non-incremental dump. */
use_deltas_for_rev = use_deltas && (incremental || i != start_rev);
SVN_ERR(get_dump_editor(&dump_editor, &dump_edit_baton, fs, to_rev,
"/", stream, feedback_stream, start_rev,
use_deltas_for_rev, FALSE, subpool));
... skipping forward (dump.c)
/* If this is the first revision of a non-incremental dump,
we're in for a full tree dump. Otherwise, we want to simply
replay the revision. */
if ((i == start_rev) && (! incremental))
... the interpretation being that if both deltas and incremental are enabled at the same time, there will not be a full-text baseline in the dump for any files actually dumped.
==========================================================================================
-----Original Message-----
From: C. Michael Pilato [mailto:cmpilato@collab.net]
Sent: Tuesday, September 30, 2008 9:29 AM
To: dev@subversion.tigris.org
Subject: Re: Bug: "svnadmin dump --incremental --deltas" gives too much output
Vincent Lefevre wrote:
> On 2008-09-30 08:08:01 -0700, Paul Charlton wrote:
>> Assume 2 revisions: (n), (n-1), containing just a few text files.
>> "dump" must export "(n):full text" (to recreate a baseline) and also
>> the difference of (n):(n-1)
>
> No, the baseline can be obtained from the previous revisions.
> "dump" does not behave as you say: try it!
Vincent, I think you understand the --incremental and --deltas option intents, but for the sake of others in this thread, allow me to clarify:
* With no options, the first revision dumped by 'svnadmin dump' will
contain a complete listing of every directory and file in the
repository, the files' fulltext contents, all properties, etc.
Subsequent dumped revisions have the same but only for files and
directories changed in that revision.
* All that --incremental does is make that first dumped revision
like the others by only representing the files/dirs changed in that
revision.
* --deltas causes 'svnadmin dump' to use binary deltas instead of
fulltexts to represent file contents.
Sadly, 'svnadmin help's usage message isn't very helpful, because it uses "diff vs. fulltext" to describe for --incremental instead of "changed paths vs. all paths".
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
RE: Bug: "svnadmin dump --incremental --deltas" gives too much output
Posted by Paul Charlton <te...@byiq.com>.
Michael --
shouldn't we also change the doc comment in "svn_repos.h" ???
best,
Paul
-----Original Message-----
From: C. Michael Pilato [mailto:cmpilato@collab.net]
Sent: Tuesday, September 30, 2008 9:39 AM
To: dev@subversion.tigris.org
Subject: Re: Bug: "svnadmin dump --incremental --deltas" gives too much output
C. Michael Pilato wrote:
> Sadly, 'svnadmin help's usage message isn't very helpful, because it
> uses "diff vs. fulltext" to describe for --incremental instead of
> "changed paths vs. all paths".
Fixed in r33361. 'svnadmin help dump' now reads:
...
Dump the contents of filesystem to stdout in a 'dumpfile'
portable format, sending feedback to stderr. Dump revisions
LOWER rev through UPPER rev. If no revisions are given, dump all
revision trees. If only LOWER is given, dump that one revision tree.
If --incremental is passed, the first revision dumped will describe
only the paths changed in that revision; otherwise it will describe
every path present in the repository as of that revision. (In either
case, the second and subsequent revisions, if any, describe only paths
changed in those revisions.)
...
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug: "svnadmin dump --incremental --deltas" gives too much output
Posted by "C. Michael Pilato" <cm...@collab.net>.
C. Michael Pilato wrote:
> Sadly, 'svnadmin help's usage message isn't very helpful, because it uses
> "diff vs. fulltext" to describe for --incremental instead of "changed paths
> vs. all paths".
Fixed in r33361. 'svnadmin help dump' now reads:
...
Dump the contents of filesystem to stdout in a 'dumpfile'
portable format, sending feedback to stderr. Dump revisions
LOWER rev through UPPER rev. If no revisions are given, dump all
revision trees. If only LOWER is given, dump that one revision tree.
If --incremental is passed, the first revision dumped will describe
only the paths changed in that revision; otherwise it will describe
every path present in the repository as of that revision. (In either
case, the second and subsequent revisions, if any, describe only paths
changed in those revisions.)
...
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Bug: "svnadmin dump --incremental --deltas" gives too much output
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2011-12-26 00:51:51 +0100, Vincent Lefevre wrote:
> Actually the --incremental option doesn't matter. For instance, it
> is not useful when doing a dump from revision 0, and I get exactly
> the same bug, as said below.
[...]
I forgot to say that I did these tests with Subversion 1.6.17 (r1128011)
from the Debian/unstable package.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: Bug: "svnadmin dump --incremental --deltas" gives too much output
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2009-01-06 23:00:40 +0100, Vincent Lefevre wrote:
> On 2009-01-06 11:20:20 -0500, C. Michael Pilato wrote:
> > I've been sitting on this thread for a looooooooong time. Still no time to
> > really invest here, but I filed issue #3353 so we don't lose this discussion
> > forever.
>
> This is not just a documentation bug: with --incremental --deltas,
> I get a delta on the changed files only (as expected), but the delta
> is too big: it contains a lot of text that hasn't changed. The problem
> is much more important in the latest revisions than in the first ones.
Actually the --incremental option doesn't matter. For instance, it
is not useful when doing a dump from revision 0, and I get exactly
the same bug, as said below.
I've attached two files showing the problem. I've obtained them with:
$ svn diff -c3876 file:///home/vlefevre/private/svn-mpfr > mpfr-diff
$ svnadmin dump --incremental --deltas ~/private/svn-mpfr -r3876 > mpfr-dump
$ ll mpfr-*
-rw-r--r-- 1 vlefevre vlefevre 2590 2011-12-25 22:38:31 mpfr-diff
-rw-r--r-- 1 vlefevre vlefevre 9333 2011-12-25 22:38:34 mpfr-dump
on my own copy of the MPFR repository (to be able to use svnadmin).
This corresponds to a ChangeLog update (note: CVS was used at that
time, and the repository was converted to Subversion later). One
can see in mpfr-diff that there are changes only for 2005-09. But
in mpfr-dump, one can see text corresponding to 2005-09, 2004-09,
2003-01, and 2001-10. Text corresponding to 2001..2004 shouldn't
have appeared as nothing has changed!
I get the same data for the revision 3876 (i.e. removing everything
that doesn't belong to this revision) whether I do
svnadmin dump --incremental --deltas ~/private/svn-mpfr -r3876
or I do
svnadmin dump --deltas ~/private/svn-mpfr -r 0:3876
showing that --incremental doesn't matter regarding this bug.
--
Vincent Lef�vre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Ar�naire project (LIP, ENS-Lyon)
Re: Bug: "svnadmin dump --incremental --deltas" gives too much
output
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2009-01-06 11:20:20 -0500, C. Michael Pilato wrote:
> I've been sitting on this thread for a looooooooong time. Still no time to
> really invest here, but I filed issue #3353 so we don't lose this discussion
> forever.
This is not just a documentation bug: with --incremental --deltas,
I get a delta on the changed files only (as expected), but the delta
is too big: it contains a lot of text that hasn't changed. The problem
is much more important in the latest revisions than in the first ones.
for i in `svn log -v file:///home/vlefevre/private/svn-mpfr/trunk/ChangeLog | sed -n -e 's/^r\([0-9]\+\).*/\1/p'`
do
svnadmin dump --incremental --deltas ~/private/svn-mpfr -r$i | wc -c
svn diff -c$i file:///home/vlefevre/private/svn-mpfr | wc -c
done
* Dumped revision 5629.
988544
222754
* Dumped revision 4743.
298218
38373
* Dumped revision 4605.
586864
1655916
* Dumped revision 3888.
6099
1805
* Dumped revision 3876.
9209
2590
* Dumped revision 3856.
8452
2459
* Dumped revision 3832.
3233
1086
* Dumped revision 3824.
3833
1143
* Dumped revision 3817.
3003
1118
* Dumped revision 3809.
711
621
* Dumped revision 3808.
2678
903
* Dumped revision 3797.
22692
6214
* Dumped revision 3736.
2454
795
* Dumped revision 3733.
839
445
* Dumped revision 3731.
1905
692
* Dumped revision 3728.
12874
3583
* Dumped revision 3694.
2862
1382
* Dumped revision 3689.
77445
20915
* Dumped revision 3538.
13254
4084
* Dumped revision 3514.
14255
4267
* Dumped revision 3474.
58842
16535
* Dumped revision 3334.
23795
6400
* Dumped revision 3324.
17981
40983
* Dumped revision 3279.
40355
10886
* Dumped revision 3213.
65816
17591
* Dumped revision 3062.
7707
2112
* Dumped revision 3054.
12311
3400
* Dumped revision 3030.
21741
7690
* Dumped revision 2967.
54113
19199
* Dumped revision 2791.
47266
16847
* Dumped revision 2664.
75584
27850
* Dumped revision 2503.
23798
9079
* Dumped revision 2450.
56143
20707
* Dumped revision 2302.
47004
22993
* Dumped revision 2124.
7338
4038
* Dumped revision 2085.
15879
8530
* Dumped revision 2004.
6094
3210
* Dumped revision 1982.
4245
2465
* Dumped revision 1956.
2654
1457
* Dumped revision 1946.
16333
9101
* Dumped revision 1942.
766
390
* Dumped revision 1884.
931
520
* Dumped revision 1881.
4898
3590
* Dumped revision 1870.
1045
589
* Dumped revision 1867.
1075
581
* Dumped revision 1864.
1712
967
* Dumped revision 1854.
1647
1142
* Dumped revision 1845.
1333
862
* Dumped revision 1842.
2525
1457
* Dumped revision 1830.
917
1187
* Dumped revision 1826.
1983
1215
* Dumped revision 1824.
6770
4210
* Dumped revision 1810.
1277
688
* Dumped revision 1806.
1375
799
* Dumped revision 1799.
877
506
* Dumped revision 1796.
54941
158127
* Dumped revision 665.
14277
26668
Revisions 665 and 4605 are a bit special. It seems that the result on
revision 1796 is due to compression by "svnadmin dump". I also wonder
why sometimes text is compressed, sometimes it isn't.
--
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 / Arenaire project (LIP, ENS-Lyon)
Re: Bug: "svnadmin dump --incremental --deltas" gives too much
output
Posted by "C. Michael Pilato" <cm...@collab.net>.
I've been sitting on this thread for a looooooooong time. Still no time to
really invest here, but I filed issue #3353 so we don't lose this discussion
forever.
Paul Charlton wrote:
> good spelunking! your matrix and reduction show how the code actually behaves ... although I am not sure which of the dumps is actually useful for backup or repository synchronization.
>
> best,
> Paul
>
> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> Sent: Tuesday, September 30, 2008 11:09 AM
> To: Paul Charlton
> Cc: dev@subversion.tigris.org
> Subject: Re: Bug: "svnadmin dump --incremental --deltas" gives too much output
>
> Paul Charlton wrote:
>> for completeness, the doc comment in "svn_repos.h" covers the behavior
>> of "--deltas" accurately, in that it states:
>>
>> * If @a use_deltas is @c TRUE, output only node properties which have
>> * changed relative to the previous contents, and output text contents
>> * as svndiff data against the previous contents. Regardless of how
>> * this flag is set, the first revision of a non-incremental dump will
>> * be done with full plain text. A dump with @a use_deltas set cannot
>> * be loaded by Subversion 1.0.x.
>
> Wow. What a complex matrix of behavior. If I'm reading the code correctly, the first revision of a dump will use fulltexts instead of binary deltas regardless of whether "--deltas" was provided, unless both --deltas and --incremental were provided (in which case it uses binary deltas). I think.
> Is this right?
>
> deltas | incrmnt | 1st rev | behavior
> --------+---------+---------+------------------------
> 0 | 0 | 0 | changed paths, fulltext
> --------+---------+---------+------------------------
> 0 | 0 | 1 | full tree, fulltext
> --------+---------+---------+------------------------
> 0 | 1 | 0 | changed paths, fulltext
> --------+---------+---------+------------------------
> 0 | 1 | 1 | changed paths, fulltext
> --------+---------+---------+------------------------
> 1 | 0 | 0 | changed paths, deltas
> --------+---------+---------+------------------------
> 1 | 0 | 1 | full tree, fulltext
> --------+---------+---------+------------------------
> 1 | 1 | 0 | changed paths, deltas
> --------+---------+---------+------------------------
> 1 | 1 | 1 | changed paths, deltas
>
> So, reduction brings (check me, here):
>
> incremental = (incremental || (! first_rev));
> deltas = deltas && !(!incremental && first_rev)
> = deltas && (incremental || !first_rev);
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1007805
RE: Bug: "svnadmin dump --incremental --deltas" gives too much output
Posted by Paul Charlton <te...@byiq.com>.
good spelunking! your matrix and reduction show how the code actually behaves ... although I am not sure which of the dumps is actually useful for backup or repository synchronization.
best,
Paul
-----Original Message-----
From: C. Michael Pilato [mailto:cmpilato@collab.net]
Sent: Tuesday, September 30, 2008 11:09 AM
To: Paul Charlton
Cc: dev@subversion.tigris.org
Subject: Re: Bug: "svnadmin dump --incremental --deltas" gives too much output
Paul Charlton wrote:
> for completeness, the doc comment in "svn_repos.h" covers the behavior
> of "--deltas" accurately, in that it states:
>
> * If @a use_deltas is @c TRUE, output only node properties which have
> * changed relative to the previous contents, and output text contents
> * as svndiff data against the previous contents. Regardless of how
> * this flag is set, the first revision of a non-incremental dump will
> * be done with full plain text. A dump with @a use_deltas set cannot
> * be loaded by Subversion 1.0.x.
Wow. What a complex matrix of behavior. If I'm reading the code correctly, the first revision of a dump will use fulltexts instead of binary deltas regardless of whether "--deltas" was provided, unless both --deltas and --incremental were provided (in which case it uses binary deltas). I think.
Is this right?
deltas | incrmnt | 1st rev | behavior
--------+---------+---------+------------------------
0 | 0 | 0 | changed paths, fulltext
--------+---------+---------+------------------------
0 | 0 | 1 | full tree, fulltext
--------+---------+---------+------------------------
0 | 1 | 0 | changed paths, fulltext
--------+---------+---------+------------------------
0 | 1 | 1 | changed paths, fulltext
--------+---------+---------+------------------------
1 | 0 | 0 | changed paths, deltas
--------+---------+---------+------------------------
1 | 0 | 1 | full tree, fulltext
--------+---------+---------+------------------------
1 | 1 | 0 | changed paths, deltas
--------+---------+---------+------------------------
1 | 1 | 1 | changed paths, deltas
So, reduction brings (check me, here):
incremental = (incremental || (! first_rev));
deltas = deltas && !(!incremental && first_rev)
= deltas && (incremental || !first_rev);
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug: "svnadmin dump --incremental --deltas" gives too much output
Posted by "C. Michael Pilato" <cm...@collab.net>.
Paul Charlton wrote:
> for completeness, the doc comment in "svn_repos.h" covers the behavior
> of "--deltas" accurately, in that it states:
>
> * If @a use_deltas is @c TRUE, output only node properties which have
> * changed relative to the previous contents, and output text contents
> * as svndiff data against the previous contents. Regardless of how
> * this flag is set, the first revision of a non-incremental dump will
> * be done with full plain text. A dump with @a use_deltas set cannot
> * be loaded by Subversion 1.0.x.
Wow. What a complex matrix of behavior. If I'm reading the code correctly,
the first revision of a dump will use fulltexts instead of binary deltas
regardless of whether "--deltas" was provided, unless both --deltas and
--incremental were provided (in which case it uses binary deltas). I think.
Is this right?
deltas | incrmnt | 1st rev | behavior
--------+---------+---------+------------------------
0 | 0 | 0 | changed paths, fulltext
--------+---------+---------+------------------------
0 | 0 | 1 | full tree, fulltext
--------+---------+---------+------------------------
0 | 1 | 0 | changed paths, fulltext
--------+---------+---------+------------------------
0 | 1 | 1 | changed paths, fulltext
--------+---------+---------+------------------------
1 | 0 | 0 | changed paths, deltas
--------+---------+---------+------------------------
1 | 0 | 1 | full tree, fulltext
--------+---------+---------+------------------------
1 | 1 | 0 | changed paths, deltas
--------+---------+---------+------------------------
1 | 1 | 1 | changed paths, deltas
So, reduction brings (check me, here):
incremental = (incremental || (! first_rev));
deltas = deltas && !(!incremental && first_rev)
= deltas && (incremental || !first_rev);
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
RE: Bug: "svnadmin dump --incremental --deltas" gives too much output
Posted by Paul Charlton <te...@byiq.com>.
for completeness, the doc comment in "svn_repos.h" covers the behavior of "--deltas" accurately, in that it states:
* If @a use_deltas is @c TRUE, output only node properties which have
* changed relative to the previous contents, and output text contents
* as svndiff data against the previous contents. Regardless of how
* this flag is set, the first revision of a non-incremental dump will
* be done with full plain text. A dump with @a use_deltas set cannot
* be loaded by Subversion 1.0.x.
*
(emphasis added)
-----Original Message-----
From: C. Michael Pilato [mailto:cmpilato@collab.net]
Sent: Tuesday, September 30, 2008 9:29 AM
To: dev@subversion.tigris.org
Subject: Re: Bug: "svnadmin dump --incremental --deltas" gives too much output
Vincent Lefevre wrote:
> On 2008-09-30 08:08:01 -0700, Paul Charlton wrote:
>> Assume 2 revisions: (n), (n-1), containing just a few text files.
>> "dump" must export "(n):full text" (to recreate a baseline) and also
>> the difference of (n):(n-1)
>
> No, the baseline can be obtained from the previous revisions.
> "dump" does not behave as you say: try it!
Vincent, I think you understand the --incremental and --deltas option intents, but for the sake of others in this thread, allow me to clarify:
* With no options, the first revision dumped by 'svnadmin dump' will
contain a complete listing of every directory and file in the
repository, the files' fulltext contents, all properties, etc.
Subsequent dumped revisions have the same but only for files and
directories changed in that revision.
* All that --incremental does is make that first dumped revision
like the others by only representing the files/dirs changed in that
revision.
* --deltas causes 'svnadmin dump' to use binary deltas instead of
fulltexts to represent file contents.
Sadly, 'svnadmin help's usage message isn't very helpful, because it uses "diff vs. fulltext" to describe for --incremental instead of "changed paths vs. all paths".
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Bug: "svnadmin dump --incremental --deltas" gives too much output
Posted by "C. Michael Pilato" <cm...@collab.net>.
Vincent Lefevre wrote:
> On 2008-09-30 08:08:01 -0700, Paul Charlton wrote:
>> Assume 2 revisions: (n), (n-1), containing just a few text files.
>> "dump" must export "(n):full text" (to recreate a baseline) and also the
>> difference of (n):(n-1)
>
> No, the baseline can be obtained from the previous revisions.
> "dump" does not behave as you say: try it!
Vincent, I think you understand the --incremental and --deltas option
intents, but for the sake of others in this thread, allow me to clarify:
* With no options, the first revision dumped by 'svnadmin dump' will
contain a complete listing of every directory and file in the
repository, the files' fulltext contents, all properties, etc.
Subsequent dumped revisions have the same but only for files and
directories changed in that revision.
* All that --incremental does is make that first dumped revision
like the others by only representing the files/dirs changed in that
revision.
* --deltas causes 'svnadmin dump' to use binary deltas instead of
fulltexts to represent file contents.
Sadly, 'svnadmin help's usage message isn't very helpful, because it uses
"diff vs. fulltext" to describe for --incremental instead of "changed paths
vs. all paths".
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Bug: "svnadmin dump --incremental --deltas" gives too much
output
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2008-09-30 08:08:01 -0700, Paul Charlton wrote:
> Assume 2 revisions: (n), (n-1), containing just a few text files.
> "dump" must export "(n):full text" (to recreate a baseline) and also the
> difference of (n):(n-1)
No, the baseline can be obtained from the previous revisions.
"dump" does not behave as you say: try it!
Note: even for the ChangeLog file on which I'm seeing too much output,
one doesn't have the full text (some parts are missing and the baseline
cannot be recreated from the incremental dump only); and for the other
files in the dump, I just get the difference (n):(n-1) as expected.
> Can you cite which documentation led to the understanding that you express
> in your email?
"The second useful option is --deltas. This option causes svnadmin
dump to, instead of emitting full-text representations of file
contents and property lists, emit only deltas of those items against
their previous versions."
So, this is a bit like diff, but on binary data.
--
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 / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Bug: "svnadmin dump --incremental --deltas" gives too much output
Posted by Paul Charlton <te...@byiq.com>.
Vincent,
Overall, this does not seem like a bug unless the documentation set the
wrong expectation.
"dump" and "diff" serve entirely different purposes. Specifically, "dump"
must export enough information to recreate the subject files in a new
repository, while "diff" only needs to export enough information to recreate
the subject file in the originating repository.
Assume 2 revisions: (n), (n-1), containing just a few text files.
"dump" must export "(n):full text" (to recreate a baseline) and also the
difference of (n):(n-1)
"diff" must only export the difference of (n):(n-1)
You will see the efficiencies of "svnadmin dump --incremental --deltas" when
there are many revisions in the dump when compared to the same dump from
"svnadmin dump --incremental"
Can you cite which documentation led to the understanding that you express
in your email?
best,
Paul
-----Original Message-----
From: Vincent Lefevre [mailto:vincent+svn@vinc17.org]
Sent: Tuesday, September 30, 2008 4:24 AM
To: dev@subversion.tigris.org
Subject: Re: Bug: "svnadmin dump --incremental --deltas" gives too much
output
I can reproduce this problem on the MPFR repository (revision 5629).
So, if someone needs a testcase, this is possible (but quite large).
FYI, this happens on updates of ChangeLog files.
For the MPFR case:
svn diff -> 222778 bytes
svnadmin dump --incremental --deltas (version 1.1.4) -> 311751 bytes
svnadmin dump --incremental --deltas (version 1.5.1) -> 988544 bytes
The dump with 1.1.4 was obtained on the MPFR svn server itself.
The dump with 1.5.1 was obtained on a different machine, after
rebuilding a repository from the full dump.
--
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 / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
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