Test case: f init x.fossil mkdir x cd x f open ../x.fossil touch file1 file2 f add * f commit -m 1 echo hello > file2 f commit -branch branch -m 2 f up trunk echo hello2 > file1 f commit -m 3 f merge -integrate branch f commit -m 4
Now the /reports?view=byfile page shows file1 and file2 as having three
check-ins each. This is clearly incorrect.
It's not 100% clear how this is intended to be measured for file2, but
for file1 there were definitely only two check-ins. This is a bug in
need of fixing, and (other than the next paragraph) the rest of this
email deals with it.
file2 is in a gray area. It appears in three check-ins, but the last
such check-in was a merge in which the branch version was pulled onto
trunk without further modification. How do we want to count this?
Now, to explore the bug... will start over and take this step by step.
f init x.fossil
mkdir x
cd x
f open ../x.fossil
touch file1 file2
f add *
f commit -m ci-1 -tag ci-1
echo hello > file2
f commit -m ci-2 -tag c1-2
echo there > file2
f commit -m ci-3 -tag ci-3
echo hello > file3
f add file3
f commit -m ci-4 -tag ci-4
At this point, /reports?view=byfile shows:
- file1: 1 check-in
- file2: 3 check-ins
- file3: 1 check-in
This is correct. Let's continue...
f up ci-1
echo hello > file1
f commit -branch br-1 -m ci-5 -tag ci-5
Now the by-file report shows:
- file1: 2 check-ins
- file2: 3 check-ins
- file3: 1 check-in
Also good.
f up trunk
f merge br-1
f commit -m ci-6 -tag ci-6
Now the by-file report shows:
- file1: 3 check-ins
- file2: 4 check-ins
- file3: 2 check-ins
Uh oh. file1's count was incremented, which is good. But so was the
count of every file that had been modified between br-1's baseline and
merge, which is bad.
What's wrong? Let's have a look at the repository database. Rewind
history, and at each point where I showed the by-file report, I'll show
you the database, using "sqlite3 -column -header ../x.fossil" and this
query:
SELECT name, mid, comment
FROM filename NATURAL JOIN mlink, event
WHERE mlink.mid = event.objid
ORDER BY name;
Immediately after "f commit -m ci-4 -tag ci-4"...
name mid comment
---------- ---------- ----------
file1 3 ci-1
file2 3 ci-1
file2 5 ci-2
file2 7 ci-3
file3 8 ci-4
Immediately after "f commit -branch br-1 -m ci-5 -tag ci-5"...
name mid comment
---------- ---------- ----------
file1 3 ci-1
file1 9 ci-5
file2 3 ci-1
file2 5 ci-2
file2 7 ci-3
file3 8 ci-4
And now the naughty. Following "f commit -m ci-6 -tag ci-6"...
name mid comment
---------- ---------- ----------
file1 3 ci-1
file1 9 ci-5
file1 10 ci-6
file2 3 ci-1
file2 5 ci-2
file2 7 ci-3
file2 10 ci-6
file3 8 ci-4
file3 10 ci-6
The problem is all those mid=10 comment=ci-6 rows. There should be only
one for file1, but file2 and file3 are also linked to ci-6, i.e. the
fatal merge.
--
Andy Goth | <andrew.m.goth/at/gmail/dot/com>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
