You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Berlin <db...@dberlin.org> on 2006/02/08 13:55:29 UTC
Re: Should 'svnadmin dump --deltas' write svndiff1 diffs? (was Re:
svn commit: r18363)
On Wed, 2006-02-08 at 08:47 -0500, C. Michael Pilato wrote:
> Malcolm Rowe wrote:
> >>If so, we probably should add a --no-svndiff1 option to dump as well.
> >
> > No, I think that's the wrong way round - we don't want people using
> > revision-based 'dump --deltas' for backup purposes to suddenly find that
> > they're using a format that can only be read by svnadmin 1.4.x.
> >
> > Better would be either to always write svndiff0 (people can pipe it
> > through gzip if they want, and may already be doing so), or perhaps to
> > provide a '--svndiff1' option to write svndiff1 deltas. We could even
> > look at inferring a default from the filesystem version, though I think
> > we might need both --svndiff1 and --svndiff0 options to override it in
> > that case.
>
> I agree. The dumpfile format should continue to use the most widely
> handled formats until the format itself *needs* to be bump in order to
> carry information that the existing format cannot carry. A switch from
> svndiff0 to svndiff1 in the dumpfile format is not necessary, and
> therefore should not not occur at all. If we want to provide a
> --svndiff1 option to 'svnadmin dump', that's fine with me -- at least
> folks will have to work a little harder to hurt themselves.
I have absolutely no strong feelings on the issue because we have made
incompatible changes to the dump format before, with no backwards
compatibility option (though maybe this occurred before 1.0).
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Should 'svnadmin dump --deltas' write svndiff1 diffs? (was Re:
svn commit: r18363)
Posted by Daniel Berlin <db...@dberlin.org>.
On Wed, 2006-02-08 at 16:48 +0000, Malcolm Rowe wrote:
> On Wed, Feb 08, 2006 at 08:55:29AM -0500, Daniel Berlin wrote:
> > On Wed, 2006-02-08 at 08:47 -0500, C. Michael Pilato wrote:
> > > I agree. The dumpfile format should continue to use the most widely
> > > handled formats until the format itself *needs* to be bump in order to
> > > carry information that the existing format cannot carry. A switch from
> > > svndiff0 to svndiff1 in the dumpfile format is not necessary, and
> > > therefore should not not occur at all. If we want to provide a
> > > --svndiff1 option to 'svnadmin dump', that's fine with me -- at least
> > > folks will have to work a little harder to hurt themselves.
> >
> > I have absolutely no strong feelings on the issue because we have made
> > incompatible changes to the dump format before, with no backwards
> > compatibility option (though maybe this occurred before 1.0).
> >
>
> Yes, the --deltas option was introduced in 1.1.0, and produces dumps
> that can't be read by 1.0.x. For 1.4.0, we could introduce dumpfile
> format version 4 (and specify that it always contains svndiff1 deltas),
> but I don't think we would want to make it the default.
Okay .......
>
> Sounds like we should at the least switch back to svndiff0 deltas for
> the current delta dumps. Any objections to me doing that now?
Not from me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Should 'svnadmin dump --deltas' write svndiff1 diffs? (was Re:
svn commit: r18363)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Daniel Berlin wrote:
>>So while the --deltas option saves quite a bit of space,
>>'--deltas' + gzip is actually better than '--deltas --svndiff1', or even
>>'--deltas --svndiff1' + gzip. In this case anyway.
>
>
> This will always be the case.
>
> 1. Even with the deltas, there is still significant plain text in the
> dump file.
> 2. gzip will get to see larger pieces than we do.
>
> we only get to encode one delta at a time.
>
> Depending on the size of your files and deltas, gzip is going to get to
> compress seeing multiple deltas at once.
Yep. It's not a surprise at all, and is definitely *not* a poor
reflection on svndiff1's goodness over svndiff0 -- thanks, Daniel!
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Should 'svnadmin dump --deltas' write svndiff1 diffs? (was Re:
svn commit: r18363)
Posted by Daniel Berlin <db...@dberlin.org>.
> So while the --deltas option saves quite a bit of space,
> '--deltas' + gzip is actually better than '--deltas --svndiff1', or even
> '--deltas --svndiff1' + gzip. In this case anyway.
This will always be the case.
1. Even with the deltas, there is still significant plain text in the
dump file.
2. gzip will get to see larger pieces than we do.
we only get to encode one delta at a time.
Depending on the size of your files and deltas, gzip is going to get to
compress seeing multiple deltas at once.
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Should 'svnadmin dump --deltas' write svndiff1 diffs? (was Re: svn commit: r18363)
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Wed, Feb 08, 2006 at 11:55:21AM -0500, C. Michael Pilato wrote:
> Malcolm Rowe wrote:
> > Yes, the --deltas option was introduced in 1.1.0, and produces dumps
> > that can't be read by 1.0.x.
>
> ... and is not the default. The default invocation of 'svnadmin dump'
> remains compatible with older versions.
>
Yes, forgot that bit. It's important.
> > Sounds like we should at the least switch back to svndiff0 deltas for
> > the current delta dumps. Any objections to me doing that now? (We can
> > continue to discuss exactly whether or how we should expose the svndiff1
> > deltas in our dumpstreams, of course).
>
> +1 on switching back to svndiff0 as the default.
>
Okay, done: r18394.
For anyone wondering about the size differences, I did a quick test with
my own (very small) personal repository:
svnadmin dump {version 2 dumpstream} 18Mb, 100%
compressed with gzip 18.4%
--deltas {version 3, svndiff0} 8.8%
compressed with gzip 3.5%
--deltas {version 3, svndiff1} 6.5%
compressed with gzip 4.0%
So while the --deltas option saves quite a bit of space,
'--deltas' + gzip is actually better than '--deltas --svndiff1', or even
'--deltas --svndiff1' + gzip. In this case anyway.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Should 'svnadmin dump --deltas' write svndiff1 diffs? (was Re:
svn commit: r18363)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Malcolm Rowe wrote:
> Yes, the --deltas option was introduced in 1.1.0, and produces dumps
> that can't be read by 1.0.x.
... and is not the default. The default invocation of 'svnadmin dump'
remains compatible with older versions.
> Sounds like we should at the least switch back to svndiff0 deltas for
> the current delta dumps. Any objections to me doing that now? (We can
> continue to discuss exactly whether or how we should expose the svndiff1
> deltas in our dumpstreams, of course).
+1 on switching back to svndiff0 as the default.
We can add a --svndiff1 option later, which will, when used with
--deltas, cause a dumpstream with a bumped version number (what are we
at, 3?) to be generated.
To be clear about what I'm thinking:
(no options): dumpstream version 2, no deltas (and thus,
svndiff-independent)
--deltas: dumpstream version 3, svndiff0 deltas
--deltas --svndiff1: dumpstream version 4, svndiff1 deltas
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Should 'svnadmin dump --deltas' write svndiff1 diffs? (was Re: svn commit: r18363)
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Wed, Feb 08, 2006 at 08:55:29AM -0500, Daniel Berlin wrote:
> On Wed, 2006-02-08 at 08:47 -0500, C. Michael Pilato wrote:
> > I agree. The dumpfile format should continue to use the most widely
> > handled formats until the format itself *needs* to be bump in order to
> > carry information that the existing format cannot carry. A switch from
> > svndiff0 to svndiff1 in the dumpfile format is not necessary, and
> > therefore should not not occur at all. If we want to provide a
> > --svndiff1 option to 'svnadmin dump', that's fine with me -- at least
> > folks will have to work a little harder to hurt themselves.
>
> I have absolutely no strong feelings on the issue because we have made
> incompatible changes to the dump format before, with no backwards
> compatibility option (though maybe this occurred before 1.0).
>
Yes, the --deltas option was introduced in 1.1.0, and produces dumps
that can't be read by 1.0.x. For 1.4.0, we could introduce dumpfile
format version 4 (and specify that it always contains svndiff1 deltas),
but I don't think we would want to make it the default.
Sounds like we should at the least switch back to svndiff0 deltas for
the current delta dumps. Any objections to me doing that now? (We can
continue to discuss exactly whether or how we should expose the svndiff1
deltas in our dumpstreams, of course).
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Should 'svnadmin dump --deltas' write svndiff1 diffs? (was Re: svn commit: r18363)
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Wed, Feb 08, 2006 at 07:19:31AM -0800, Michael Brouwer wrote:
> Won't svndiff1 format dumpfiles be significantly smaller than
> svndiff0? In that case the option is definitely worth having, though
> I'm not sure what the default should be.
>
You could pipe the svndiff0-format output through gzip and you'll get
practically the same output, so the option isn't critical.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Should 'svnadmin dump --deltas' write svndiff1 diffs? (was Re: svn commit: r18363)
Posted by Michael Brouwer <mb...@gmail.com>.
Won't svndiff1 format dumpfiles be significantly smaller than
svndiff0? In that case the option is definitely worth having, though
I'm not sure what the default should be.
Michael
On 2/8/06, Daniel Berlin <db...@dberlin.org> wrote:
> On Wed, 2006-02-08 at 08:47 -0500, C. Michael Pilato wrote:
> > Malcolm Rowe wrote:
> > >>If so, we probably should add a --no-svndiff1 option to dump as well.
> > >
> > > No, I think that's the wrong way round - we don't want people using
> > > revision-based 'dump --deltas' for backup purposes to suddenly find that
> > > they're using a format that can only be read by svnadmin 1.4.x.
> > >
> > > Better would be either to always write svndiff0 (people can pipe it
> > > through gzip if they want, and may already be doing so), or perhaps to
> > > provide a '--svndiff1' option to write svndiff1 deltas. We could even
> > > look at inferring a default from the filesystem version, though I think
> > > we might need both --svndiff1 and --svndiff0 options to override it in
> > > that case.
> >
> > I agree. The dumpfile format should continue to use the most widely
> > handled formats until the format itself *needs* to be bump in order to
> > carry information that the existing format cannot carry. A switch from
> > svndiff0 to svndiff1 in the dumpfile format is not necessary, and
> > therefore should not not occur at all. If we want to provide a
> > --svndiff1 option to 'svnadmin dump', that's fine with me -- at least
> > folks will have to work a little harder to hurt themselves.
>
> I have absolutely no strong feelings on the issue because we have made
> incompatible changes to the dump format before, with no backwards
> compatibility option (though maybe this occurred before 1.0).
>
> --Dan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>