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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.