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

Re: [PATCH] svn_fs_text_changed

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2003-11-26 05:22:23 CET

Philip Martin <philip@codematters.co.uk> writes:

> "C. Michael Pilato" <cmpilato@collab.net> writes:
>
> > Philip Martin <philip@codematters.co.uk> writes:
> >>
> >> You didn't make a branch, so there's no history relating dir1 to dir2,
> >> without history we always send delete plus add.
> >
> > Diff and merge pass the ignore_ancestry flag to dir-delta, which tells
> > that sucker to not pay attention to relatedness,
>
> I'd forgotten about that change.
>
> > It's not the output that I'm concerned with. It's the extra work
> > happening under the hood. If you still have your test scenario above,
> > set a breakpoint on repos_diff.c:window_handler. If you even once see
> > a non-NULL window, Subversion is being inefficient. And that's what I
> > was seeing.
>
> Using HEAD, one window_handler() call per file has a non-NULL
> window. Adding/removing --notice-ancestry makes no difference.

Right. That non-NULL window says (effectively), "grab all the source
file's bytes."

I still have some remaining doubt and confusion about textdeltas. My
assumption here is that the goal of a textdelta (in the general case)
is to inform you about how to construct some fulltext given some other
fulltext. What is the expected outcome from a no-op textdelta then (a
single, NULL window)? Does that mean, "You're final outcome should be
the empty file", or "You're final outcome is exactly the same as your
source file"?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 26 05:25:01 2003

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