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

--Dan

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