> My guess is that you are probably overflowing a 32-bit integer
> someplace. If so, I fear that this will not be something easily
> fixed.
>
Looks like it's the case at least in one place.
There's int64 => unsigned int overflow at the call to blob_resize()
(blob.c:865
On Aug 6, 2018, at 11:30 AM, Philip Bennefall wrote:
>
> a second commit right afterwards caused a segfault again
In advance of drh getting time to work on this, maybe you could give two
debugging steps on your end:
1. If you’re doing this on a platform that will run Valgrind, try running a
On 8/6/18, Philip Bennefall wrote:
> But I wanted to report our experience in case it is of use to the
> developers, and in case doing so could give us some assistance with the
> immediate issue.
Thank you for the report. This is definitely something that should be
fixed. But I have a large
The following command solved the issue at least for the moment:
fossil rebuild --vacuum --analyze --compress
I'm not yet sure which of the options made the difference, but I wanted
to report back nevertheless.
Kind regards,
Philip Bennefall
On 8/6/2018 6:57 PM, Philip Bennefall wrote:
OK.
On 8/6/18, Richard Hipp wrote:
> On 8/6/18, Philip Bennefall wrote:
>> Do you have any recommendations for something we could try in order to
>> get more information, or would you suggest that we switch to another
>> DVCS if we need to store files of these sizes?
>
> Regardless of the problem, I
OK. I'll investigate. Thanks for the quick response.
Kind regards,
Philip Bennefall
On 8/6/2018 6:50 PM, Richard Hipp wrote:
On 8/6/18, Philip Bennefall wrote:
Do you have any recommendations for something we could try in order to
get more information, or would you suggest that we switch
On 8/6/18, Philip Bennefall wrote:
> Do you have any recommendations for something we could try in order to
> get more information, or would you suggest that we switch to another
> DVCS if we need to store files of these sizes?
Regardless of the problem, I don't think *any* DVCS is appropriate
Do you have any recommendations for something we could try in order to
get more information, or would you suggest that we switch to another
DVCS if we need to store files of these sizes?
Kind regards,
Philip Bennefall
On 8/6/2018 6:33 PM, Richard Hipp wrote:
On 8/6/18, Philip Bennefall
On 8/6/18, Philip Bennefall wrote:
> We have a repository in our organization which stores a number of rather
> large binary files. When attempting to commit, we sometimes get
> something like this:
>
>
> ERROR: [largefile.bin is 999378424 bytes on disk but 210746789 in the
> repository
My guess
Additional information: The repo checksum is disabled locally. When
enabling it, we get:
Segmentation fault: 11
Kind regards,
Philip Bennefall
On 8/6/2018 6:11 PM, Philip Bennefall wrote:
We have a repository in our organization which stores a number of
rather large binary files. When
We have a repository in our organization which stores a number of rather
large binary files. When attempting to commit, we sometimes get
something like this:
ERROR: [largefile.bin is 999378424 bytes on disk but 210746789 in the
repository
The file in question was not modified during the
That worked. According to the changes command, 136 history files
removed, 81 new history files added, and 22 files were edited.
The commit completed without error this time. So I guess I will
make a batch file to do those three commands for when I do a commit.
-
On 3/26/18, Scott Doctor wrote:
> I ran the stash command and got the following:
>
> no such file: D/water/C/slave/__history/main.c.~15~
Probably this mean that you previously committed the file main.c.~15~
but it was subsequently deleted without you doing "fossil rm".
If
I ran the stash command and got the following:
no such file: D/water/C/slave/__history/main.c.~15~
I am writing code for several Atmel (now Microchip) sam4s Arm
processora using Atmel Studio IDE. This is built on Microsloths
Visual Studio. The system automatically makes many history
On Mar 26, 2018, at 1:27 PM, Scott Doctor wrote:
>
> aborting due to prior errors
I’ve seen that sort of message on “fossil update” when a local file is marked
read-only and the file was changed on the remote system.
Obviously that is not exactly what is happening here,
On 3/26/18, Scott Doctor wrote:
>
> I just typed:
>
> fossil commit
>
> All I wanted to do was take a snapshot of the current state in
> case I wanted to back out of my changes after my forthcoming
> edit session. Am I doing this wrong?
You seem to be doing it right. I
I just typed:
fossil commit
All I wanted to do was take a snapshot of the current state in
case I wanted to back out of my changes after my forthcoming
edit session. Am I doing this wrong?
-
Scott Doctor
sc...@scottdoctor.com
-
On 3/26/2018
On 26 March 2018 at 12:27, Scott Doctor wrote:
>
> A while back I created a new repository for a project I ressurected. Checked
> it after creating with the fossil ui that all files included and such.
> Everything OK.
>
> My project contains many folders and a couple
On 3/26/18, Scott Doctor wrote:
> That is the entirety of the error message. Such is the problem I
> am having trying to find what is the error. The error message
> displayed, then returned to the command line prompt
OK. Without seeing the output, I can't suggest much.
I emailed you the _FOSSIL_ file for the repository
-
Scott Doctor
sc...@scottdoctor.com
-
On 3/26/2018 12:42, Richard Hipp wrote:
On 3/26/18, Scott Doctor wrote:
A bunch of file names scrolled up the screen then got the
That is the entirety of the error message. Such is the problem I
am having trying to find what is the error. The error message
displayed, then returned to the command line prompt
-
Scott Doctor
sc...@scottdoctor.com
-
On 3/26/2018 12:42, Richard
On 3/26/18, Scott Doctor wrote:
>
> A bunch of file names scrolled up the screen then got the message:
>
> aborting due to prior errors
>
More details on the error message would be helpful.
--
D. Richard Hipp
d...@sqlite.org
___
A while back I created a new repository for a project I
ressurected. Checked it after creating with the fossil ui that
all files included and such. Everything OK.
My project contains many folders and a couple hundred files for
a multi processor embedded application. Been working on the
ons later) work well.
>
> (If anyone has a quicker method, please enlighten us.)
>
> -Original Message- From: Aldo Nicolas Bruno
> Sent: Monday, December 05, 2016 11:44 PM
> To: Fossil SCM user's discussion
> Subject: Possible Spam(10.041):[fossil-users] error in commit
>
> Hi
.
(If anyone has a quicker method, please enlighten us.)
-Original Message-
From: Aldo Nicolas Bruno
Sent: Monday, December 05, 2016 11:44 PM
To: Fossil SCM user's discussion
Subject: Possible Spam(10.041):[fossil-users] error in commit
Hi,
By mistake I've made an error and did fossil
) work well.
-Original Message-
From: Aldo Nicolas Bruno
Sent: Monday, December 05, 2016 11:44 PM
To: Fossil SCM user's discussion
Subject: Possible Spam(10.041):[fossil-users] error in commit
Hi,
By mistake I've made an error and did fossil commit -m "added lalal"
without specif
Hi,
By mistake I've made an error and did fossil commit -m "added lalal"
without specifying which files to commit, so it commited all the changed
files... but my intention was to commit only some files...
There is a way to elegantly undo the commit or modify it so as to
exclude some files?
Thanks
27 matches
Mail list logo