View Ticket
Ticket UUID: f0f9aff371f26b4eebb1ded3cabc70c956c6cae7
Title: 'annotate' misses changes.
Status: Closed Type: Code_Defect
Severity: Important Priority:
Subsystem: Resolution: Fixed
Last Modified: 2011-10-19 20:16:18
Version Found In: [047e06193b] 2011-04-13
Description & Comments:
I've a branch where I'm interested on the source of this line of code, at point 2011-04-28:
const bool debugErrorToFile = true;

Looking at annotate, I see:

ad13e86e1e 2010-09-28  llbatlle:     const bool debugErrorToFile = true;

I don't trust it.. and I find a commit in the same branch, on 2011-04-08, that introduced the change. So, annotate was not showing it.

I write a commit today (2011-05-05), setting back the debugErrorToFile to false. Then I test annotate again, expecting to see the very recent commit. But I get:

8c918ba0e2 2010-10-25  llbatlle:     const bool debugErrorToFile = false;

So, annotate is getting confused somehow. I can completely reproduce it, but I cannot give the repository as it contains private files.

viriketo added on 2011-05-05 15:16:35 UTC:
Just testing the most recent commit in this repository: [74c86dd1da6]

Notice that the diff says:

+  if( showClosed ){
+    db_prepare(&q,
+      "SELECT value FROM tagxref"
+      " WHERE tagid=%d AND value NOT NULL "
+      "EXCEPT "

while annotate says

74c86dd1da 2011-05-04       drh:   if( showClosed ){
518439507a 2010-08-15       drh:     db_prepare(&q,        <== This line
74c86dd1da 2011-05-04       drh:       "SELECT value FROM tagxref"
74c86dd1da 2011-05-04       drh:       " WHERE tagid=%d AND value NOT NULL "
74c86dd1da 2011-05-04       drh:       "EXCEPT "

viriketo added on 2011-05-05 21:43:57 UTC:
I think the problem has to do with line numbering. Look at this: version of the branch.c above looking at all the lines and their numbers. There are many wrong line numbers.

viriketo added on 2011-05-05 21:48:17 UTC:
Sorry. Reloading the page I see the line numbers fine. I think my previous comment misleads, as I think it was due to a problem in my browser, and not in fossil.

viriketo added on 2011-05-05 22:00:38 UTC:
From what I see in diff.c:688 and diff.c:771, the annotate procedure goes by looking at older and older commits, and when parts of the lines are equal, the older commit is taken.

I think that this makes the 'annotate' show, sometimes, "the earliest commit with that change", instead of "the last commit with that change".

Other VCS show in 'annotate' the last change in every given line. This is the behaviour I'd prefer, but I barely know anything about diff algorithms, so I hope someone takes the job of implementing this usual kind of annotate.

viriketo added on 2011-05-06 19:15:41 UTC:
Sorry, but I reopen the ticket.

I'm trying the fossil version [9a63d1f048] 2011-05-06, which should have the changes that brought the ticket into Fixed.

As I said in the initial ticket entry, I had committed const bool debugErrorToFile = false; in 2011-05-05. If I use 'annotate' on that file with the new fossil version, I get:

f794dd718d 2011-03-01  llbatlle:     const bool debugErrorToFile = false;

which is different than before your changes, but still wrong.

viriketo added on 2011-05-06 19:18:48 UTC:
I'm trying fossil annotate --limit 1 FILE, and although the file was modified on 2011-05-05, it shows all the file annotations in 2011-03-01. So there may be a problem on getting the initial version.

viriketo added on 2011-05-06 19:27:18 UTC:
I just noticed that the *web* annotate shows good results. It's only the *commandline* annotate showing the troubles.

viriketo added on 2011-05-07 14:14:54 UTC:
I investigated a bit more... the terminal 'annotate' uses a query like this:

  mid = db_int(0, "SELECT mid FROM mlink WHERE fid=%d AND fnid=%d", fid, fnid);

that does not give a SINGLE result. Different checkins may have the very same file artifact, and it needs further code to decide what checkin is of interest.

Then, it needs some code to choose what is of the interest of the requester.

viriketo added on 2011-10-19 20:16:18 UTC:
Merged to trunk on [e161670939].