On Mon, 2005-12-12 at 23:39 +0000, Julian Foad wrote:
> Daniel Berlin wrote:
> > So svndiff1 is ready to merge.
>
> Can you give us a summary of what this branch does?
In the simplest sense, we now support zlib encoding of the new data and
instruction sections of the delta format.
The advantage is twofold:
1. When you merge things around from trunk to branch, there is often a
lot of new data in the svndiff it generates. None of it was previously
compressed. This causes rev files to be quite large when you are
maintaining multiple branches.
The reason for this is because we relied on vdelta doing okay as an
"encoder" instead of just relying on it as a difference generator.
Since we always used vdelta, we never needed to encode the output of
vdelta all that well.
xdelta doesn't do target side copies, because they massively slow down
delta combination. However, zlib compressing the new data section after
running xdelta gives you better results than vdelta did anyway.
2. You no longer need to use vdelta for "self-compression" if you don't
want. You get better results (speed and size wise) if you just make a
single op containing the new data, and zlib compress the new data.
ideally, we could just turn off using vdelta as a generator for
svndiff1, but of course, the encoder is not aware of what generated the
deltas.
It's better to just wait a few versions, or 2.0, then remove vdelta
usage (you'll get no "compression" of the resulting data if you don't
use svndiff1 in that case, hence the waiting till svndiff1 becomes the
predominant format. Might even wait for 2.0)
> The summary of the major
> commit on the branch (r17225) is:
>
> Add new svndiff1 diff encoding.
>
> ... which is a bit on the brief side :-) I seem to recall you gave a good
> description of it in an email a while ago; perhaps you could retrieve and
> update that, probably making it just a paragraph or two for the log message for
> the merge to trunk. Of course the format details will be in 'notes/svndiff',
> so all this log message needs to say is basically why and what is the effect of
> this enhancement.
>
> > On an average repository, the savings are abut 30% disk space with
> > roughly no time cost (I haven't seen the zlib encoding/decoding on the
> > profiles).
>
> That certainly sounds good!
>
> > There are some questions exactly what we should be outputting and
> > handling in mod_dav_svn/neon in terms of headers, and i'm happy to
> > address any concerns, because I have no real opinions/etc about whether
> > we should be using Accept/Accept-Encoding, what the names, etc, we
> > should use there are, or anything of the sort :).
>
> Do you mean there are some questions that people have already asked that
> haven't yet been answered conclusively, or that you have made some arbitrary
> choices in the design which we might like to consider?
There were arbitrary choices made at the advice of Erik, who i know
understands mod_dav_svn.
There is some disagreement over whether we should be using the Accept:
header with a per-version mimetype, or Accept-Encoding like we do now.
We've always said the data consists of type
#define SVN_SVNDIFF_MIME_TYPE "application/vnd.svn-svndiff"
Which is still true.
I chose Accept-Encoding as the "negotiation" between the client and
server to determine if they support svndiff1, because svndiff1 is
specific encoding of data, much like gzip is.
Thus, the client will send
Accept: application/vnd.svn-svndiff
Accept-Encoding: svndiff1
not
Accept: application/vnd.svn-svndiff1
Again, this was all at the advice of those smarter than me in the way of
mod_dav_svn.
> Can you list these
> questions? (You mentioned one there: "Accept" or "Accept-Encoding".)
>
> (I'm just asking to try to stimulate others to discuss or review; this isn't my
> area.)
>
> > The internal bdb and fsfs formats have been bumped, but we still support
> > the "old" format simultaneously. I've added an option to svnadmin to
> > create repositories with the old format (IE svndiff0 only), for
> > backwards compatibility.
>
> That information should probably go into the log message for the merge to trunk
> if nowhere else.
Yup.
>
>
> > Index: svndiff-v1
> > ===================================================================
> > --- svndiff-v1 (revision 0)
> > +++ svndiff-v1 (revision 17225)
> > @@ -0,0 +1,222 @@
> > +This email is long, so i sectionized it into "Introduction and
> > +justification", "Changes I made", "Sparkly numbers", "Time Costs and
> > +Backwards Compatibility"
> [...]
> > +I obviously have no plans to commit this until we work out these issues,
> > +and revise the patch. Thus, style nits, etc, are not necessary. I'm
> > +aware it's non-perfect :)
> > +
> > +--Dan
> > \ No newline at end of file
>
> Ah - that looks like the body of your descriptive email that I referred to
> above. It contains some interesting information, but I don't think we need a
> verbatim copy of it in the "notes" directory.
> I'm not sure if you added on
> purpose: it's not mentioned in any of the log messages.
Sussman asked me to drop it in the notes directory.
I haven't had time to rewrite it a bit.
I've fixed the rest of the stuff you pointed out.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 13 01:03:02 2005