On 13 Aug 2002, Karl Fogel wrote:
> Daniel Berlin <dberlin@dberlin.org> writes:
> > CVS's isn't perfect.
> > It can't be.
>
> Sorry, I was being sloppy. What I should have said is, CVS tends not
> to lose any important information in annotate, and we shouldn't
> either.
>
> I understand that CVS might not be perfect, in the sense that it
> probably opts for the fast-but-not-always-optimal diff algorithm. But
> that's a choice we can tune, right?
>
> Let's take a line-based text file, so we're talking explicitly about
> the case that "cvs ann" works on.
>
> Rev 1: Obviously, all lines belong to the first committer.
>
> Rev 2: Any deleted lines go away. Any changed lines belong to the
> new committer. Any added lines belong to the new committer.
>
> Rev 3: See Rev 2.
>
> And so on, and so on.
>
> So the question reduces to determining what happened to which lines in
> a given commit, which boils down to the diffing algorithm's ability to
> determine what happened. If we're using GNU diff, there are various
> flags (--minimal, --horizon-lines, --speed-large-files) that can
> affect speed, correctness, or both. This gets more and more expensive
> as we approach true perfection, so probably we want to settle for "as
> close to perfection as CVS gets".
>
> IOW, my point in my earlier mail was really that we shouldn't choose a
> solution that gives noticeably worse results than "cvs ann". I should
> have said that more clearly.
>
> Are the svndiff-based proposals leading toward an equivalent level of
> correctness?
No, but we only need new data structures if diffing the fulltexts is too
slow, which i'm actually not convinced it is right now, even for files
with 100's of revisions.
One would *think* it is, but that's not a certainty.
>
> -K
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 13 19:35:06 2002