Re: [fossil-users] fossil info on tag & directory: SQLITE_CANTOPEN

2017-07-11 Thread jungle boogie 

On 07/11/2017 06:30 PM, Richard Hipp wrote:

On 7/11/17, jungle Boogie  wrote:


I don't think the -v works:
https://www.fossil-scm.org/index.html/help?cmd=info



What were you expecting it to do?



Your commit is welcomed!
Just one minor nitpick here:
https://www.fossil-scm.org/index.html/help?cmd=info

I think you want to say:
If the argument is a repository name, then the --verbose option shows
the known

Sorry for the trouble!
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil info on tag & directory: SQLITE_CANTOPEN

2017-07-11 Thread jungle boogie 

On 07/11/2017 06:30 PM, Richard Hipp wrote:

On 7/11/17, jungle Boogie  wrote:


I don't think the -v works:
https://www.fossil-scm.org/index.html/help?cmd=info



What were you expecting it to do?



Well that's a good question.

With and without the -v seem to produce the same output.
I'd either expect: 'fossil info' to show less info or 'fossil info -v' 
to show more info than it currently does.


The help page says "Show extra information".

Thanks
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil info on tag & directory: SQLITE_CANTOPEN

2017-07-11 Thread Richard Hipp 
On 7/11/17, jungle Boogie  wrote:
>
> I don't think the -v works:
> https://www.fossil-scm.org/index.html/help?cmd=info
>

What were you expecting it to do?

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil info on tag & directory: SQLITE_CANTOPEN

2017-07-11 Thread jungle boogie 

On 07/11/2017 04:57 PM, jungle Boogie wrote:

On 11 July 2017 at 16:41, Richard Hipp  wrote:

On 7/11/17, jungle Boogie  wrote:


Is there at least a workaround in Fossil to report info on a tag if
there's a directory with the same name? Using the webapp I suppose it
a workaround.



fossil info tag:stuff



Ah, indeed that is nice!

I don't think the -v works:
https://www.fossil-scm.org/index.html/help?cmd=info



Looks like it was added here:
https://www.fossil-scm.org/index.html/info/5214a2a8b894b7b6


Does it work for anyone?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil info on tag & directory: SQLITE_CANTOPEN

2017-07-11 Thread jungle Boogie 
On 11 July 2017 at 16:41, Richard Hipp  wrote:
> On 7/11/17, jungle Boogie  wrote:
>>
>> Is there at least a workaround in Fossil to report info on a tag if
>> there's a directory with the same name? Using the webapp I suppose it
>> a workaround.
>>
>
> fossil info tag:stuff
>

Ah, indeed that is nice!

I don't think the -v works:
https://www.fossil-scm.org/index.html/help?cmd=info


$ fossil info -v release
uuid: 036ebf729e4b21035d7f4f8e35a6f705e6bf9988 2017-06-17 09:59:36 UTC
parent:   e1b71029087675749a5c64303a8756d16cb33ed3 2017-06-17 00:39:47 UTC
tags: release, branch-3.18, version-3.18.2
comment:  Version 3.18.2 (user: drh)

$ fossil info -v tag:release
uuid: 036ebf729e4b21035d7f4f8e35a6f705e6bf9988 2017-06-17 09:59:36 UTC
parent:   e1b71029087675749a5c64303a8756d16cb33ed3 2017-06-17 00:39:47 UTC
tags: release, branch-3.18, version-3.18.2
comment:  Version 3.18.2 (user: drh)


$ fossil info
project-name: SQLite
repository:   /home/jungle/fossil-repos/sqlite/../sqlite.fossil
local-root:   /home/jungle/fossil-repos/sqlite/
config-db:/home/jungle/.fossil
project-code: 2ab58778c2967968b94284e989e43dc11791f548
checkout: 39069941e98605bc8c7c736819781761760ee2b8 2017-07-11 20:36:35 UTC
parent:   b0a49d90fc91acca1306cf6145adc83acd368686 2017-07-11 19:55:38 UTC
tags: trunk
comment:  In lsm, attempt to unmap the database file before
truncating it when disconnecting. A mapped file may not be truncated
on win32. (user: dan)
check-ins:19056

$ fossil info -v
project-name: SQLite
repository:   /home/jungle/fossil-repos/sqlite/../sqlite.fossil
local-root:   /home/jungle/fossil-repos/sqlite/
config-db:/home/jungle/.fossil
project-code: 2ab58778c2967968b94284e989e43dc11791f548
checkout: 39069941e98605bc8c7c736819781761760ee2b8 2017-07-11 20:36:35 UTC
parent:   b0a49d90fc91acca1306cf6145adc83acd368686 2017-07-11 19:55:38 UTC
tags: trunk
comment:  In lsm, attempt to unmap the database file before
truncating it when disconnecting. A mapped file may not be truncated
on win32. (user: dan)
check-ins:19056



> --
> D. Richard Hipp
> d...@sqlite.org

---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil info on tag & directory: SQLITE_CANTOPEN

2017-07-11 Thread Richard Hipp 
On 7/11/17, jungle Boogie  wrote:
>
> Is there at least a workaround in Fossil to report info on a tag if
> there's a directory with the same name? Using the webapp I suppose it
> a workaround.
>

fossil info tag:stuff

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil info on tag & directory: SQLITE_CANTOPEN

2017-07-11 Thread jungle Boogie 
On 11 July 2017 at 15:14, Warren Young  wrote:
> On Jul 11, 2017, at 12:32 AM, jungle boogie  wrote:
>>
>> % fossil info stuff
>>
>> But that results in this error:
>> SQLITE_CANTOPEN: cannot open file at line 36100 of [284707a7b3]
>> SQLITE_CANTOPEN: os_unix.c:36100: (21) 
>> open(/usr/home/jungle/fossil-repos/repo/stuff) - Is a directory
>> fossil: [stuff]: unable to open database file
>>
>> So can a tag not have the same name as its directory?
>
> That’s not it.  If you give a file name here, Fossil assumes it is a 
> repository file, and fails to open it if it isn’t a file.   You can cause the 
> same error with “fossil info .”
>

Ah, indeed I do trip over the same SQLITECANTOPEN warning when
specifying the current directory.

> Very early in my Fossil indoctrination process, I had the “svn info filename” 
> habit beaten out of my finger memory because “fossil info” simply doesn’t do 
> the same thing as “svn info”.   Consequently, my ongoing assumption up to 
> this thread was that “fossil info” doesn’t accept file names; that’s what 
> “finfo” is for.
>

Right, finfo is very nice for that.

> That aside, I think the thing for Fossil to do here is to try looking for a 
> VERSION match before testing whether the parameter names a local file.  The 
> chances of a local repository file name matching a tag or version hash in the 
> local repository are far smaller than having a tag or version that just 
> happens to match the name of a local file.

Is there at least a workaround in Fossil to report info on a tag if
there's a directory with the same name? Using the webapp I suppose it
a workaround.

Thanks!


-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] diff for browse.c

2017-07-11 Thread Warren Young 
On Jul 11, 2017, at 3:58 PM, Warren Young  wrote:
> 
>https://en.wiktionary.org/wiki/actual (noun sense 1)

2!
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil info on tag & directory: SQLITE_CANTOPEN

2017-07-11 Thread Warren Young 
On Jul 11, 2017, at 12:32 AM, jungle boogie  wrote:
> 
> % fossil info stuff
> 
> But that results in this error:
> SQLITE_CANTOPEN: cannot open file at line 36100 of [284707a7b3]
> SQLITE_CANTOPEN: os_unix.c:36100: (21) 
> open(/usr/home/jungle/fossil-repos/repo/stuff) - Is a directory
> fossil: [stuff]: unable to open database file
> 
> So can a tag not have the same name as its directory?

That’s not it.  If you give a file name here, Fossil assumes it is a repository 
file, and fails to open it if it isn’t a file.   You can cause the same error 
with “fossil info .”

Very early in my Fossil indoctrination process, I had the “svn info filename” 
habit beaten out of my finger memory because “fossil info” simply doesn’t do 
the same thing as “svn info”.   Consequently, my ongoing assumption up to this 
thread was that “fossil info” doesn’t accept file names; that’s what “finfo” is 
for.

That aside, I think the thing for Fossil to do here is to try looking for a 
VERSION match before testing whether the parameter names a local file.  The 
chances of a local repository file name matching a tag or version hash in the 
local repository are far smaller than having a tag or version that just happens 
to match the name of a local file.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil info on tag & directory: SQLITE_CANTOPEN

2017-07-11 Thread jungle Boogie 
On 10 July 2017 at 23:32, jungle boogie  wrote:
> Hi All,
>
> Maybe this is a bad practice on my part, let me know.
>

Is that the case with this?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] diff for browse.c

2017-07-11 Thread Warren Young 
On Jul 11, 2017, at 1:52 AM, Stephan Beal  wrote:
> 
> Related trivia: native German speakers, regardless of whether they're 
> functionally fluent in English, can often be identified in internet forums 
> via their overuse of commas

Another telltale is the implicit subject in sentences meant to refer to the 
reader, as in “This feature allows to set the framistating rate.”  Idiomatic 
English requires a definite subject here, but apparently German does not, since 
I’ve seen this across multiple native German speakers writing in English.

I haven’t bothered to try and associate it with any specific language family, 
but another oddity I’ve frequently seen from ESL[*] types is to use “software” 
as a singular noun: “I wrote a new software today.”  In idiomatic English, the 
singular of “software” is “program.”  Ain’t English fun? :)


[*] English as a Second Language

> and their use of the word "actual", which is used differently in German - if 
> someone writes "the actual version of the software is ..." when you would 
> have said "current version" then they're most likely a native German speaker

That word has a lot of strange uses, as in “Galactica Actual.”

https://en.wiktionary.org/wiki/actual (noun sense 1)

And if you don’t get that reference, turn in your nerd card right now. ;)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] diff for browse.c

2017-07-11 Thread jungle Boogie 
On 10 July 2017 at 19:19, Warren Young  wrote:
> On Jul 10, 2017, at 5:56 PM, Richard Hipp  wrote:
>>
>> On 7/10/17, jungle Boogie  wrote:
>>> Hi All,
>>>
>>> One very minor update to browse.c to add a comma:
>>
>> I don't think that comma is correct.  The most important comma rule I
>> was taught in 8th grade was "if in doubt, leave it out".  And I don't
>> see a compelling reason to include that comma.
>
> The comma belongs:
>
> https://www.grammarly.com/blog/comma-before-which/
> http://grammar.ccc.commnet.edu/Grammar/commas.htm  (item 4)
>
> Because the “which” clause only adds information and does not change the 
> essential meaning of the remaining sentence if dropped, you need the comma.
>

Exactly my thoughts - restrictive vs. non-restrictive.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] IP address changes for www.fossil-scm.org

2017-07-11 Thread Richard Hipp 
Due to upstream infrastructure changes, the IPv4 address for
fossil-scm.org is changing.  (The IPv6 address will remain the same, I
am told.)  I *think* I have updated all of the DNS entries correctly
and reconfigured the server properly to handle this change.  However,
the mysteries of Ubuntu are great.  If you encounter trouble reaching
the website, or this mailing list, in the next few days, please send
email directly to me.  Thanks.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug Report Update 2: Fossil Server side Corrupts if Client Process is Killed

2017-07-11 Thread Stephan Beal 
On Tue, Jul 11, 2017 at 2:26 PM, Richard Hipp  wrote:

> Can you start, please, by describing what hardware you are using


Related to that: is any repo accessed via a networked drive. (If so, then
"don't do that.")

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug Report Update 2: Fossil Server side Corrupts if Client Process is Killed

2017-07-11 Thread Richard Hipp 
On 7/11/17, Martin Vahi  wrote:
>
> After doing the
>
> fossil rebuild
>
> at the server side, central repository side,
> I get the following line at the client side:
>
> Fossil internal error: infinite loop in DELTA table

That is definitely a problem, if it is reproducible.

Here's the thing, Martin:  Thousands and thousands of people use
Fossil every day (we know this from server logs) and have been doing
so for 10 years, and nobody has ever before had these kinds of
problems.  Then suddenly you appear and start reporting a whole bunch
of repository corruption issues that nobody has ever seen before.  You
must be doing something really unusual to be getting all of these
problems.  We'd like to get to the bottom of why Fossil is not working
for you when it works so well for so many other people.  But in order
to do that, we need to back up and figure out what it is you are doing
differently from everybody else.

Can you start, please, by describing what hardware you are using, then
provide us with a detailed discussion of what you are trying to do
with Fossil and what steps you are using to a achieve those goals?


>
> citation--start
> COMMENTS.txt
> milestone_releases/currently_there_is_none.txt
> project-name: 
> repository:
> /home/ts2/Projektid/progremise_infrastruktuur/andmevahetustarkvara/rakendusvõrgud/silktorrent/publitseerimishoidla/repository_storage.fossil
> local-root:
> /opt/2dot7TiB_k8vaketas/ts2/mittevarundatav/hiljem_siiski_varundatav/Projektid/progremise_infrastruktuur/andmevahetustarkvara/rakendusvõrgud/silktorrent/publitseerimishoidla/sandbox_of_the_Fossil_repository/
> config-db:
> /home/ts2/m_local/bin_p/fossil_scm_org/vd2017_04_28/.fossil
> project-code: 26101fc480a34b3b993c8c83b7511840ab9d0c17
> checkout: 336bc431b271e19ae40a2824a5523e6c1cba447a 2016-05-14
> 08:07:53 UTC
> parent:   2a2e3765cab0b0074208f20f02f177025648d6df 2015-01-31
> 16:44:26 UTC
> tags: trunk
> comment:  folder layout (user: martin_vahi)
> check-ins:2
> Pull from
> https://martin_v...@www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/home
> Round-trips: 1   Artifacts sent: 0  received: 14
> Fossil internal error: infinite loop in DELTA table
> citation--end--
>
> I changed the passwords at my online copy of the
> Fossil repository server side version and placed the old
> version with old passwords at
>
>
> https://temporary.softf1.com/2017/bugs/2017_07_11_server_side_Fossil_repository_of_the_bug_where_Ctrl_C_of_Fossil_client_currupts_SQLite_of_the_server.fossilrepository
>
> It's about 5GiB, but may be it helps with debugging.
>
> Thank You.
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug Report Update 1: Failure to Recover when Previous Fossil Process got Killed

2017-07-11 Thread Richard Hipp 
On 7/11/17, Martin Vahi  wrote:
>
> The cloning of the remote repository does not
> give me all of the files that the remote repository
> Web GUI shows to be present. The remote repository URL is:

It seems to work when I try this.  What files are you missing?

>
>
> https://www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/home
>
>
> Could someone please write,
> how can I get the cloning to properly work again?
>


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug Report Update 1: Failure to Recover when Previous Fossil Process got Killed

2017-07-11 Thread Richard Hipp 
On 7/11/17, Martin Vahi  wrote:
>
> If I log into the web GUI of the remote Fossil repository
> and use the
>
> Admin -> Shunned -> Rebuild
>
> then the web GUI shows me:
>
> ---citation--start
>
> SQLITE_ERROR: no such table: ftsidx_segments

I think that bug was fixed here:
https://www.fossil-scm.org/fossil/timeline?y=ci=3200a7c72e41e783a16f

The repository should have recovered automatically.  To work around
the problem, disable full-text search for the repository prior to
running the rebuild.  Or (better) upgrade to the latest trunk version
of Fossil.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug Report: Failure to Recover when Previous Fossil Process got Killed

2017-07-11 Thread Richard Hipp 
On 7/11/17, Martin Vahi  wrote:
>
> it would be nice, if the
> Fossil were able to recover from that kind of situations
> itself, automatically.

Fossil *does* recover from situations like this automatically

In this case, I don't think the prior fossil command was killed
unexpectedly.  Instead, I think the command is hung and is running in
the background.  If you were to kill off the hung instance of Fossil,
then the next fossil command would automatically recover the
repository to a sane state.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Bug Report Update 2: Fossil Server side Corrupts if Client Process is Killed

2017-07-11 Thread Martin Vahi 

After doing the

fossil rebuild

at the server side, central repository side,
I get the following line at the client side:

Fossil internal error: infinite loop in DELTA table

citation--start
COMMENTS.txt
milestone_releases/currently_there_is_none.txt
project-name: 
repository:
/home/ts2/Projektid/progremise_infrastruktuur/andmevahetustarkvara/rakendusvõrgud/silktorrent/publitseerimishoidla/repository_storage.fossil
local-root:
/opt/2dot7TiB_k8vaketas/ts2/mittevarundatav/hiljem_siiski_varundatav/Projektid/progremise_infrastruktuur/andmevahetustarkvara/rakendusvõrgud/silktorrent/publitseerimishoidla/sandbox_of_the_Fossil_repository/
config-db:
/home/ts2/m_local/bin_p/fossil_scm_org/vd2017_04_28/.fossil
project-code: 26101fc480a34b3b993c8c83b7511840ab9d0c17
checkout: 336bc431b271e19ae40a2824a5523e6c1cba447a 2016-05-14
08:07:53 UTC
parent:   2a2e3765cab0b0074208f20f02f177025648d6df 2015-01-31
16:44:26 UTC
tags: trunk
comment:  folder layout (user: martin_vahi)
check-ins:2
Pull from
https://martin_v...@www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/home
Round-trips: 1   Artifacts sent: 0  received: 14
Fossil internal error: infinite loop in DELTA table
citation--end--

I changed the passwords at my online copy of the
Fossil repository server side version and placed the old
version with old passwords at


https://temporary.softf1.com/2017/bugs/2017_07_11_server_side_Fossil_repository_of_the_bug_where_Ctrl_C_of_Fossil_client_currupts_SQLite_of_the_server.fossilrepository

It's about 5GiB, but may be it helps with debugging.

Thank You.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug Report Update 1: Failure to Recover when Previous Fossil Process got Killed

2017-07-11 Thread Stephan Beal 
On Tue, Jul 11, 2017 at 11:25 AM, Martin Vahi 
wrote:

>
> If I log into the web GUI of the remote Fossil repository
> and use the
>
> Admin -> Shunned -> Rebuild
>
> then the web GUI shows me:
>
> ---citation--start
>
> SQLITE_ERROR: no such table: ftsidx_segments
>
> Database Error
>
> no such table: ftsidx_segments:
> { DROP TABLE "ftsidx_segments"; DROP TABLE "ftsidx_segdir";
> DROP TABLE "ftsidx_docsize"; DROP TABLE "ftsidx_stat"; }


i'm fairly certain that that was fixed recently:

http://fossil-scm.org/index.html/info/3200a7c72e41e783


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Bug Report Update 1: Failure to Recover when Previous Fossil Process got Killed

2017-07-11 Thread Martin Vahi 

If I log into the web GUI of the remote Fossil repository
and use the

Admin -> Shunned -> Rebuild

then the web GUI shows me:

---citation--start

SQLITE_ERROR: no such table: ftsidx_segments

Database Error

no such table: ftsidx_segments:
{ DROP TABLE "ftsidx_segments"; DROP TABLE "ftsidx_segdir";
DROP TABLE "ftsidx_docsize"; DROP TABLE "ftsidx_stat"; }

---citation--end-


The cloning of the remote repository does not
give me all of the files that the remote repository
Web GUI shows to be present. The remote repository URL is:


https://www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/home


Could someone please write,
how can I get the cloning to properly work again?

Thank You.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Bug Report: Failure to Recover when Previous Fossil Process got Killed

2017-07-11 Thread Martin Vahi 

I do not know the exact operation that I killed by
the key combination Ctrl-C, but the operation was probably
one of the following:

fossil addremove
or
fossil commit
or
fossil pull
or
fossil push

The result is a "corrupted" repository file with a
"locked SQLite" database file.

I have not lost any data, because I can make a
clean clone of the remote/server repository and re-insert
the new files to the clone, but it would be nice, if the
Fossil were able to recover from that kind of situations
itself, automatically. In my view killing a program
at an arbitrary moment, in this case, killing the Fossil client, and then
restarting the program should not disrupt the work flow of
the end user/human. The Fossil client should just continue from
where it left off without requiring any manual intervention from
the end user.

Slightly edited excerpts of the console session:

$ fossil version
This is fossil version 2.2 [81d7d3f43e] 2017-04-11 20:54:55 UTC
$ uname -a
Linux linux-0fiz 3.16.7-53-desktop #1 SMP PREEMPT Fri Dec 2 13:19:28 UTC
2016 (7b4a1f9) x86_64 x86_64 x86_64 GNU/Linux



$ fossil ui ./repository_storage.fossil
Listening for HTTP requests on TCP port 8080
[14674:14674:0711/113948:ERROR:sandbox_linux.cc(343)]
InitializeSandbox() called with multiple threads in process gpu-process.
[14641:14747:0711/113949:ERROR:connection.cc(1892)] History sqlite error
5, errno 0: database is locked, sql: PRAGMA auto_vacuum
[14641:14747:0711/113949:ERROR:connection.cc(1892)] History sqlite error
5, errno 0: database is locked, sql: PRAGMA journal_mode = TRUNCATE
[14641:14660:0711/113949:ERROR:connection.cc(1892)] Web sqlite error 5,
errno 0: database is locked, sql: PRAGMA auto_vacuum
[14641:14660:0711/113949:ERROR:connection.cc(1892)] Web sqlite error 5,
errno 0: database is locked, sql: PRAGMA journal_mode = TRUNCATE
[14641:14747:0711/113950:ERROR:connection.cc(1892)] History sqlite error
5, errno 0: database is locked, sql: PRAGMA cache_size=1000
[14641:14747:0711/113950:ERROR:connection.cc(1892)] History sqlite error
5, errno 0: database is locked, sql: SELECT name FROM sqlite_master
WHERE type=? AND name=? COLLATE NOCASE
[14641:14660:0711/113950:ERROR:connection.cc(1892)] Web sqlite error 5,
errno 0: database is locked, sql: PRAGMA cache_size=32
[14641:14660:0711/113950:ERROR:connection.cc(1892)] Web sqlite error 5,
errno 0: database is locked, sql: SELECT name FROM sqlite_master WHERE
type=? AND name=? COLLATE NOCASE
[14641:14660:0711/113950:ERROR:connection.cc(1892)] Web sqlite error 5,
errno 0: database is locked, sql: SELECT name FROM sqlite_master WHERE
type=? AND name=? COLLATE NOCASE
[14641:14660:0711/113950:ERROR:connection.cc(1892)] Web sqlite error 5,
errno 0: database is locked, sql: SELECT COUNT(*) FROM sqlite_master
[14641:14660:0711/113950:ERROR:connection.cc(1892)] Web sqlite error 5,
errno 0: database is locked, sql: SELECT name FROM sqlite_master WHERE
type=? AND name=? COLLATE NOCASE
[14641:14660:0711/113950:ERROR:connection.cc(1892)] Web sqlite error 5,
errno 0: database is locked, sql: CREATE TABLE meta(key LONGVARCHAR NOT
NULL UNIQUE PRIMARY KEY, value LONGVARCHAR)
[14641:14660:0711/113950:ERROR:web_database_backend.cc(113)] Cannot
initialize the web database: 1
[14641:14660:0711/113950:ERROR:connection.cc(1892)] Passwords sqlite
error 5, errno 0: database is locked, sql: PRAGMA auto_vacuum
[14641:14660:0711/113950:ERROR:connection.cc(1892)] Passwords sqlite
error 5, errno 0: database is locked, sql: PRAGMA journal_mode = TRUNCATE
[14641:14659:0711/113950:ERROR:data_store_impl.cc(129)] Failed to open
Data Reduction Proxy DB: 3
[14641:14747:0711/113950:ERROR:connection.cc(1892)] History sqlite error
5, errno 0: database is locked, sql: SELECT name FROM sqlite_master
WHERE type=? AND name=? COLLATE NOCASE
[14641:14747:0711/113950:ERROR:connection.cc(1892)] History sqlite error
5, errno 0: database is locked, sql: CREATE TABLE meta(key LONGVARCHAR
NOT NULL UNIQUE PRIMARY KEY, value LONGVARCHAR)
[14641:14660:0711/113951:ERROR:connection.cc(1892)] Passwords sqlite
error 5, errno 0: database is locked, sql: PRAGMA cache_size=32
[14641:14660:0711/113951:ERROR:connection.cc(1892)] Passwords sqlite
error 5, errno 0: database is locked, sql: SELECT name FROM
sqlite_master WHERE type=? AND name=? COLLATE NOCASE
[14641:14660:0711/113951:ERROR:connection.cc(1892)] Passwords sqlite
error 5, errno 0: database is locked, sql: SELECT name FROM
sqlite_master WHERE type=? AND name=? COLLATE NOCASE
[14641:14660:0711/113951:ERROR:connection.cc(1892)] Passwords sqlite
error 5, errno 0: database is locked, sql: CREATE TABLE meta(key
LONGVARCHAR NOT NULL UNIQUE PRIMARY KEY, value LONGVARCHAR)
[14641:14660:0711/113951:ERROR:login_database.cc(542)] Unable to create
the meta table.
[14641:14660:0711/113951:ERROR:password_store_default.cc(45)] Could not
create/open login database.
[14641:14660:0711/113951:ERROR:connection.cc(1892)] Shortcuts sqlite
error 5, errno 0: database is locked, sql: PRAGMA

Re: [fossil-users] diff for browse.c

2017-07-11 Thread Johan Kuuse 
On Tue, Jul 11, 2017 at 10:33 AM, Aaron Elkins  wrote:
>
> On Jul 11, 2017, at 15:52, Stephan Beal  wrote:
>
> On Tue, Jul 11, 2017 at 4:19 AM, Warren Young  wrote:
>>
>> You are right that commas are often overused, drh.  I catch myself doing
>> it occasionally.
>
>
> Related trivia: native German speakers, regardless of whether they're
> functionally fluent in English, can often be identified in internet forums
> via their overuse of commas (and their use of the word "actual", which is
> used differently in German - if someone writes "the actual version of the
> software is ..." when you would have said "current version" then they're
> most likely a native German speaker).

.. or, although less likely, a native Swedish, Norwegian, or
Luxembourgish speaker:
https://en.wiktionary.org/wiki/aktuell
With "less likely", I don not mean that we are less linguistically
error prone than the Germans, but we are simply less (about a tenth of
them).
And, yes, we also do love commas. :-)

/J

>
>
> Interesting saying.
>
> -Aaron
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] diff for browse.c

2017-07-11 Thread Aaron Elkins 

> On Jul 11, 2017, at 15:52, Stephan Beal  wrote:
> 
> On Tue, Jul 11, 2017 at 4:19 AM, Warren Young  > wrote:
> You are right that commas are often overused, drh.  I catch myself doing it 
> occasionally.
> 
> Related trivia: native German speakers, regardless of whether they're 
> functionally fluent in English, can often be identified in internet forums 
> via their overuse of commas (and their use of the word "actual", which is 
> used differently in German - if someone writes "the actual version of the 
> software is ..." when you would have said "current version" then they're most 
> likely a native German speaker).
> 

Interesting saying.

-Aaron___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] diff for browse.c

2017-07-11 Thread Stephan Beal 
On Tue, Jul 11, 2017 at 4:19 AM, Warren Young  wrote:

> You are right that commas are often overused, drh.  I catch myself doing
> it occasionally.
>

Related trivia: native German speakers, regardless of whether they're
functionally fluent in English, can often be identified in internet forums
via their overuse of commas (and their use of the word "actual", which is
used differently in German - if someone writes "the actual version of the
software is ..." when you would have said "current version" then they're
most likely a native German speaker).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] fossil info on tag & directory: SQLITE_CANTOPEN

2017-07-11 Thread jungle boogie 

Hi All,

Maybe this is a bad practice on my part, let me know.

I have a directory called stuff and I also have a tag called stuff. Some 
of the commits are tagged with stuff, so that I can find it easier on 
the taglist page.


This page explains I can find information about the last check-in by 
providing the tag name:

http://fossil-scm.org/index.html/doc/trunk/www/checkin_names.wiki

% fossil info stuff

But that results in this error:
SQLITE_CANTOPEN: cannot open file at line 36100 of [284707a7b3]
SQLITE_CANTOPEN: os_unix.c:36100: (21) 
open(/usr/home/jungle/fossil-repos/repo/stuff) - Is a directory

fossil: [stuff]: unable to open database file

So can a tag not have the same name as its directory?

hmmm...interesting discovery here.

% fossil info stuff -R fossil-repos/repo.fossil
uuid: b31d4527215039dd473379d5776cdae0a725bef2 2017-07-01 
20:30:02 UTC
parent:   f59bc1ed1f56ed92e2b03ae8a3ff805a9ccb9eb0 2017-07-01 
02:57:32 UTC
child:96ea26bbd3f4f4a744e05451caaa4993c5b5c289 2017-07-01 
23:50:12 UTC
merged-into:  97cdf1f623273c76d0fb2d850fc31f674a1edc67 2017-07-02 
01:15:40 UTC

tags: trunk, stuff
comment:  well, stuff has been added

Is it this from os_unix.c in sqlite:
return unixLogError(SQLITE_CANTOPEN_BKPT, "openDirectory", zDirname);

Thanks!
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users