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

Re: How to do annotate

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-08-13 19:07:11 CEST

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?

-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:24:11 2002

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.