On 13 Aug 2002, Greg Hudson wrote:
> On Tue, 2002-08-13 at 01:59, Daniel Berlin wrote:
> > 2. As you apply deltas, and generate bytes, each range of bytes generated
> > gets marked with the revision number associated with that window (if any. If
> > you don't find it in the map, it means it doesn't delineate a new
> > revision, and we assign it the previous number), which we lookup.
>
> This is too simplistic. Let me throw out some concerns. First, an
> example:
>
> SRC: foo\nbar\nbar\n
> DST: foo\nbar\nfoo\nbar\n
>
> The instructions for this delta look like:
>
> Copy 8 bytes from src offset 0
> Copy 8 bytes from src offset 8
>
> A line-based diff would notice that only the third line (bytes 8-11) was
> new in the destination. So *half* of the second copy is new, and half
> is old.
Yes, I'm aware.
But there is little that can be done that isn't going to be very fragile.
The reality is that we need not be perfect in our annotate output.
>
> Bill Tutt implied he had a way of recognizing this, by comparing the
> self-compression of SRC to the delta between SRC and DST. I'm dubious
> (it seems very fragile at best), but regardless, let's move on to
> concern number two: windows. If I insert 128K at the beginning of a
> file, then *every* window will look like new data, even though only the
> first 128K is new.
Once again, if the windows say everything is "new" in the
revision, that's life. You can't solve this problem either in a
reasonable way, unless you consider constructing the full text of every
revision, and then doing some other type of diff on them, reasonable.
>
> 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?
--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 15:58:49 2002