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

Re: Should 'svnadmin dump --deltas' write svndiff1 diffs? (was Re: svn commit: r18363)

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2006-02-08 14:55:29 CET

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).


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 8 14:56:02 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.