I'm reviving a question about a problem from a year ago that was never
satisfactorily resolved (the student gave up and never replied to my
request for --sshtrace).
This time the (new) student has not committed successfully, and on any
attempt to write gets "Unable to write to standard output:
As you may remember, I use fossil to have students submit assignments for
my courses. Last year it worked well (eventually) with some problems with
Windows.
I have 160+ students. All of their fossils are made by the same script
that creates a user with their ID and capabilities:v and a
I was getting this from “fossil stash” for no obvious reason:
fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned
char*)0)%4==0' failed.
Rebuilding both the local repo and the master repo didn’t help. Closing the
current checkout and re-opening it did.
The number of
On Tue, Feb 9, 2016 at 1:43 PM, Stephan Beal wrote:
> On Tue, Feb 9, 2016 at 1:39 PM, Richard Hipp wrote:
>
>> work regardless on Intel, but other platforms (ARM, Sparc) have
>> stricter alignment requirements.
>>
>
> i'm powering up the ARM now to try to
On 2/9/16, Stephan Beal wrote:
>
> But how does the (unsigned char *) cast on the NULL pointer affect the
> result of (z-0)?
That was my effort to convert a pointer into an integer in a way that
is portable across a variety of compilers.
--
D. Richard Hipp
On Tue, Feb 9, 2016 at 1:43 PM, Stephan Beal wrote:
> On Tue, Feb 9, 2016 at 1:39 PM, Richard Hipp wrote:
>
>> work regardless on Intel, but other platforms (ARM, Sparc) have
>> stricter alignment requirements.
>>
>
> i'm powering up the ARM now to try to
On 2/9/16, Stephan Beal wrote:
> On Tue, Feb 9, 2016 at 12:51 PM, Richard Hipp wrote:
>
>> On 2/9/16, Warren Young wrote:
>> > I was getting this from “fossil stash” for no obvious reason:
>> >
>> > fossil: ./src/delta.c:231: checksum:
On Tue, Feb 9, 2016 at 1:39 PM, Richard Hipp wrote:
> work regardless on Intel, but other platforms (ARM, Sparc) have
> stricter alignment requirements.
>
i'm powering up the ARM now to try to reproduce it.
But how does the (unsigned char *) cast on the NULL pointer affect the
On Tue, Feb 9, 2016 at 12:51 PM, Richard Hipp wrote:
> On 2/9/16, Warren Young wrote:
> > I was getting this from “fossil stash” for no obvious reason:
> >
> > fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned
> > char*)0)%4==0' failed.
>
On 2/9/16, Warren Young wrote:
> I was getting this from “fossil stash” for no obvious reason:
>
> fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned
> char*)0)%4==0' failed.
I wish you could reproduce this, because that is an important
assertion and I would
On Tue, Feb 9, 2016 at 9:22 AM, Warren Young wrote:
>
> This was with version [b8c7af5bd9], plus the patch I recently sent to the
> list, running on CentOS 5.
>
Can you post the configure/build options you used?
The trunk tests are currently running on my ARM (no idea how
Will test --no-rebuild once current rebuild is done. Thanks for the note!
On Tue, Feb 9, 2016 at 4:39 PM, Richard Hipp wrote:
> On 2/9/16, Richard Hipp wrote:
>> On 2/9/16, Karel Gardas wrote:
>>> Hello,
>>>
>>> while testing possible git ->
On 2/9/16, Karel Gardas wrote:
> Hello,
>
> while testing possible git -> fossil incremental updates of OpenBSD
> src repository I've observed majority of time is spent on something
> reported by fossil as:
>
> Rebuilding repository meta-data...
>
> Is there any trick/command
On 2/9/16, Richard Hipp wrote:
> On 2/9/16, Karel Gardas wrote:
>> Hello,
>>
>> while testing possible git -> fossil incremental updates of OpenBSD
>> src repository I've observed majority of time is spent on something
>> reported by fossil as:
>>
>>
On 2/9/16, David Mason wrote:
> As you may remember, I use fossil to have students submit assignments for
> my courses. Last year it worked well (eventually) with some problems with
> Windows.
>
> I have 160+ students. All of their fossils are made by the same script
> that
Thus said David Mason on Tue, 09 Feb 2016 15:34:26 -0500:
> There is a user dmason with capabilities s in the fossil.
Are you allowing REMOTE_USER to work in your Fossils/dmason.fossil?
$ echo "SELECT * FROM config WHERE name = 'remote_user_ok';" | fossil sql -R
Fossils/dmason.fossil
Thanks,
On 2/9/16, Karel Gardas wrote:
>
> after attempting incremental import from OpenBSD src git tree, I've
> found out that when I try to fossil open such repository I get only
> files changed by the last import and not the files held by the whole
> repository.
>
Bummer.
>
> is
Hello,
after attempting incremental import from OpenBSD src git tree, I've
found out that when I try to fossil open such repository I get only
files changed by the last import and not the files held by the whole
repository. Anyway, the repository still holds the files I'm sure:
$ sqlite3
On 2/9/16, David Mason wrote:
>
> So I cloned a sample fossil each of the 2 ways
>
> fs clone ssh://cps...@cps506.sarg.ryerson.ca xxx.fossil
> fs clone ssh://cps506.sarg.ryerson.ca/cps506-fossils/xxx.fossil xxx2.fossil
>
> These both reference sym-links to the same fossil file
On 2/9/16, David Mason wrote:
> On 9 February 2016 at 15:48, Richard Hipp wrote:
>
>> A Fossil repository is an SQLite database, and you shouldn't create
>> links (symbolic or hard) to SQLite databases.
>>
>
> Understood, but this is a very low-contention
Thus said David Mason on Tue, 09 Feb 2016 14:25:41 -0500:
> This time the (new) student has not committed successfully, and on any
> attempt to write gets "Unable to write to standard output: The pipe is
> being closed." This is using SSH/PLINK on Windows.
Is this error a client error or
On Tue, Feb 9, 2016 at 10:28 PM, Richard Hipp wrote:
> On 2/9/16, Karel Gardas wrote:
>> is this a known issue or do I do something completely wrong?
>>
>
> Neither. You are dealing with seldom-used functionality that
> apparently has never been fully
22 matches
Mail list logo