>
> >
> > Fundamentally, our binary deltas are about the most efficient way we can
> > come up with of reconstructing DST given SRC. They are not about
> > determinine what changed, either by line or by byte range.
>
> Of course.
> Thus, trying to solve problems that are impossible should not be
> worried about.
>
> If you want to do an annotate based *only* on svndiff, the output will be
> imperfect.
> But the other options are not feasible.
>
> So should we just point out the problems that we know we can't solve, or
> should we do the best we can?
This, BTW, is known as the "If life gives you oranges, make lemonade"
approach.
But seriously, svndiff is effectively an append+copy format, rather than
insert+copy, because we can't specify where the insert occurs. If we
could, things like inserting 128k of text at the front wouldn't be a
problem, but only because the delta-window would "look right". But that's
not what we have, so we can't.
Realize, however, that CVS has these same problems, just on a lesser scale
(because the granularity of it's diff is larger, and it's diff algorithm
doesn't do self-similarity). If it decides that the best way to represent
your change is to delete the first 3000 lines, and add 6000 lines to the
front in it's place, annotate will show you as having changed those 6000
lines, when you've only added 3000.
So people aren't expecting perfection (I hope, since CVS won't give it to
them in this regard either)
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 13 16:14:05 2002