Re: [PATCH] svn_fs_text_changed

Chia-liang Kao <clkao@clkao.org> writes:

> On Wed, 2003-11-26 at 00:37, C. Michael Pilato wrote:
> > > With patch: average is 4 seconds; without patch: average is 6 seconds.
> > Hey, that's good news. Now, revert your change, and do those same
> > tests after teaching your window_handler to notice no-op textdeltas.
> > Or, if you don't have time, I'd be willing to do this test comparison
> > myself -- just send me your recipe.
>
> It's quite simple: make a local import of svn tree at rev6000 or so,
> create a local branch, update the local import to trunk, do a merge to
> the local branch. Now diff the local import and the branch.

Well, I had a tough time really understanding this description. I did
this:

   $ svn import /some/dir/of/stuff file://`pwd`/repos/dir1 -m dir1
   $ svn import /some/dir/of/stuff file://`pwd`/repos/dir2 -m dir2
   $ svn diff file://`pwd`/repos/dir1 file://`pwd`/repos/dir2

And that seemed to trigger the beast. I got a whole bunch of output
that listed "Index:" lines and seperators, but empty diffs.

So I taught repos_diff.c's window_handler() and apply_textdelta() to
deal with the single-NULL-window case. But I saw no speed
improvement, and I still saw the empty contextual diff output -- two
things I did *not* expect.

Baffled, I got out my gdb.

--
The textdeltas that dir-delta are sending between two files that have
the same contents aren't single-NULL-windows.  They basically say,
"Hey, to make this file look like that file, just replace all of this
file's bytes with that file's.  So, so much that bright idea of mine.
Of course, it also reveals a serious efficiency problem with the
textdelta generator.  I mean, had I been using ra_svn or ra_dav[1], I
would have seen every byte of my files fly by over the network as data
for a massive insert op despite the fact that the same effect could be
had by saying, "To make this file look like that file, do nothing
because it already looks like that file."  Am I misunderstanding our
textdelta system at some fundamental level?
> But if people thinks it's overall a good thing, I'll polish my patch for
> the 2nd round.
There is a certain degree of symmetry with the way commits work (first
seeing if file contents truly differ, then sending those diffs).  So
it's cool with me.  Polish away.
In the meantime, I want to know what's up with our vdelta calculation
-- I hope my findings aren't exemplary of how inefficient they are in
the general case.
-- C-Mike
[1] I did later test this with ra-svn, and sure enough, I was seeing
    the entire contents fly by instead of an empty delta.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org