Re: [fossil-users] Problem on windows sync

2016-02-09 Thread David Mason
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:

[fossil-users] Write problem for SSH access to fossil

2016-02-09 Thread David Mason
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

[fossil-users] ./src/delta.c:231: checksum: Assertion failed

2016-02-09 Thread Warren Young
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

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

2016-02-09 Thread Stephan Beal
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

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

2016-02-09 Thread Richard Hipp
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

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

2016-02-09 Thread Stephan Beal
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

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

2016-02-09 Thread Richard Hipp
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:

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

2016-02-09 Thread Stephan Beal
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

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

2016-02-09 Thread Stephan Beal
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. >

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

2016-02-09 Thread Richard Hipp
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

Re: [fossil-users] ./src/delta.c:231: checksum: Assertion failed

2016-02-09 Thread Stephan Beal
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

Re: [fossil-users] Any way how to optimize/speed-up meta-data rebuild?

2016-02-09 Thread Karel Gardas
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 ->

Re: [fossil-users] Any way how to optimize/speed-up meta-data rebuild?

2016-02-09 Thread Richard Hipp
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

Re: [fossil-users] Any way how to optimize/speed-up meta-data rebuild?

2016-02-09 Thread Richard Hipp
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: >> >>

Re: [fossil-users] Write problem for SSH access to fossil

2016-02-09 Thread Richard Hipp
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

Re: [fossil-users] Write problem for SSH access to fossil

2016-02-09 Thread Andy Bradford
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,

Re: [fossil-users] Incremental import breaks repo.

2016-02-09 Thread Richard Hipp
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

[fossil-users] Incremental import breaks repo.

2016-02-09 Thread Karel Gardas
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

Re: [fossil-users] Write problem for SSH access to fossil

2016-02-09 Thread Richard Hipp
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

Re: [fossil-users] Write problem for SSH access to fossil

2016-02-09 Thread Richard Hipp
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

Re: [fossil-users] Problem on windows sync

2016-02-09 Thread Andy Bradford
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

Re: [fossil-users] Incremental import breaks repo.

2016-02-09 Thread Karel Gardas
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