You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Robert Spier <rs...@pobox.com> on 2005/05/02 05:16:42 UTC

svnadmin dump --deltas

Is there a reason (beyond backwards compatibility) that --deltas isn't
the default for svnadmin dump?

-R

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svnadmin dump --deltas

Posted by Robert Spier <rs...@pobox.com>.
Thank you Greg, Ben, and Max for the replies.

I started crafting a patch for Chapter 9 of the book, but didn't see
an obvious precedent for this kind of detail.  Instead, here's a
paragraph to be used for the book, the FAQ, or just to sit in the
archives for happy googling.

    A normal <code>svnadmin dump</code> dumps the full content of
    every revision.  The <code>--deltas</code> option will output only
    the changes from the previous revision in a binary diff format.
    This normally creates a smaller output file.  When compressed, a
    normal dumpfile will often be smaller, because it contains more
    redundant data.  There are some disadvantages to
    <code>--deltas</code>: svndumpfilter cannot operate on
    deltified-dumps.  They are also more CPU intensive to create and
    load.

(I think it needs a little massaging.)

-R

At Mon, 2 May 2005 13:33:22 +0100,
Max Bowsher wrote:
> 
> Robert Spier wrote:
> > Is there a reason (beyond backwards compatibility) that --deltas isn't
> > the default for svnadmin dump?
> 
> Svndumpfilter cannot work on them.
> 
> Full-dump + bzip2 is smaller than delta-dump + bzip2 for at least some
> kinds of data sets.
> 
> Delta-dumps are require more CPU-work to produce and consume.
> 
> Max.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svnadmin dump --deltas

Posted by Max Bowsher <ma...@ukf.net>.
Robert Spier wrote:
> Is there a reason (beyond backwards compatibility) that --deltas isn't
> the default for svnadmin dump?

Svndumpfilter cannot work on them.

Full-dump + bzip2 is smaller than delta-dump + bzip2 for at least some kinds 
of data sets.

Delta-dumps are require more CPU-work to produce and consume.

Max.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svnadmin dump --deltas

Posted by Ben Collins-Sussman <su...@collab.net>.
On May 2, 2005, at 1:07 AM, Greg Hudson wrote:

> On Mon, 2005-05-02 at 01:16, Robert Spier wrote:
>> Is there a reason (beyond backwards compatibility) that --deltas isn't
>> the default for svnadmin dump?
>
> Delta-dumped revisions are a little pickier about being reloaded in
> exactly the same order as they were dumped.  You wouldn't want to use
> svndumpfilter on them, for instance (I don't think that even works).
>
> That's not an absolutely compelling reason why full dumps should remain
> the default forever, but there's also backward-compatibility, as you
> noted.
>
>

It's also generally slower to use --deltas.  It's a time/space tradeoff.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svnadmin dump --deltas

Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2005-05-02 at 01:16, Robert Spier wrote:
> Is there a reason (beyond backwards compatibility) that --deltas isn't
> the default for svnadmin dump?

Delta-dumped revisions are a little pickier about being reloaded in
exactly the same order as they were dumped.  You wouldn't want to use
svndumpfilter on them, for instance (I don't think that even works).

That's not an absolutely compelling reason why full dumps should remain
the default forever, but there's also backward-compatibility, as you
noted.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org