On Jun 21, 2017, at 5:05 AM, Richard Hipp <d...@sqlite.org> wrote:
> 
> On 6/20/17, Warren Young <war...@etr-usa.com> wrote:
>> 
>> Since updating and installing it, I’m getting occasional aborts in
>> relatively simple tasks like fossil diff and fossil checkin.
> 
> Are these reproducible?

By “occasional” I mean that I recall making several successful checkins between 
updating to [6e6e4b1d] and seeing the problems.  Once a problem occurred, it 
was persistent until I rolled back to the prior version.

I have no idea why the earlier checkins succeeded when the later ones failed.

> Can you provide a test case?

I can’t share the repo, but I’ve dropped an abort() in front of the line I 
referenced in the prior email, so sometime today I should have a backtrace for 
you.

> you might have accidentally discovered some undesirable
> deep recursions within Fossil that need to be fixed.

Possible.  By most measures, my main repository here is larger than either that 
of SQLite or Fossil:


Repository Size:        319012864 bytes (319.0MB)
Number Of Artifacts:    111752 (9335 fulltext and 102417 deltas)
Uncompressed Artifact Size:     114547 bytes average, 39315028 bytes max, 
12800771691 bytes (12.8GB) total
Compression Ratio:      40:1
Number Of Check-ins:    63973
Number Of Files:        27846
Number Of Wiki Pages:   28
Number Of Tickets:      237
Duration Of Project:    6687 days or approximately 18.31 years.


This repository also has a more tangled history, having gone through three SCM 
conversions.  (CVS -> SVN, then SVN -> Fossil via Git.)
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Reply via email to