[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: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2006-02-08 17:48:47 CET

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
Received on Wed Feb 8 17:49:40 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.