[fossil-users] spurious db locked
Hello, from time to time, when doing 'fossil update', I get this: - $ fossil update tai_cipher Autosync: http://llbatlle@fossil/cgi-bin/sal3d Bytes Cards Artifacts Deltas Sent: 130 1 0 0 Error: Database error: database is locked UPDATE event SET mtime=(SELECT m1 FROM time_fudge WHERE mid=objid) WHERE objid IN (SELECT mid FROM time_fudge);DROP TABLE time_fudge; Received: 197 1 0 0 Total network traffic: 346 bytes sent, 463 bytes received fossil: Autosync failed -- Running update again works. Do you have any idea what is this about? What db is locked - mine, or the remote? Regards, Lluís ___ 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] spurious db locked
2012/2/8 Lluís Batlle i Rossell vi...@viric.name Hello, from time to time, when doing 'fossil update', I get this: - $ fossil update tai_cipher Autosync: http://llbatlle@fossil/cgi-bin/sal3d Bytes Cards Artifacts Deltas Sent: 130 1 0 0 Error: Database error: database is locked UPDATE event SET mtime=(SELECT m1 FROM time_fudge WHERE mid=objid) WHERE objid IN (SELECT mid FROM time_fudge);DROP TABLE time_fudge; Received: 197 1 0 0 Total network traffic: 346 bytes sent, 463 bytes received fossil: Autosync failed -- Running update again works. Do you have any idea what is this about? What db is locked - mine, or the remote? Could be either. In this case, I think it was on the remote side. Recommend you set WAL mode on the server: fossil rebuild whatever.fossil --wal --pagesize=8192 Regards, Lluís ___ 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] _FOSSIL_ file grows large
On Tue, Feb 7, 2012 at 19:26, Richard Hipp d...@sqlite.org wrote: The _FOSSIL_ file contains (among other things) your stash and your undo history. What does sqlite3_analyzer _FOSSIL_ Hmm, I just compliled/installed sqlite-3.7.10 from its fossil repo and it did build sqlite3 executable but no sqlite3_analyzer. Interestingly, target to build sqlite3_analyzer is present in sqlite-3.7.10's Makefile but it is not part of the install. I will modify Makefile and will try to build it that way. --Leo-- ___ 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_ file grows large
On Wed, Feb 8, 2012 at 9:10 AM, Leo Razoumov slonik...@gmail.com wrote: On Tue, Feb 7, 2012 at 19:26, Richard Hipp d...@sqlite.org wrote: The _FOSSIL_ file contains (among other things) your stash and your undo history. What does sqlite3_analyzer _FOSSIL_ Hmm, I just compliled/installed sqlite-3.7.10 from its fossil repo and it did build sqlite3 executable but no sqlite3_analyzer. Interestingly, target to build sqlite3_analyzer is present in sqlite-3.7.10's Makefile but it is not part of the install. I will modify Makefile and will try to build it that way. Why too much work. Just type make sqlite3_analyzer then copy the resulting binary into your $PATH. Or download a precompiled version of sqlite3_analyzer from http://www.sqlite.org/download.html --Leo-- -- 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_ file grows large
On Tue, Feb 7, 2012 at 19:26, Richard Hipp d...@sqlite.org wrote: On Tue, Feb 7, 2012 at 7:24 PM, Leo Razoumov slonik...@gmail.com wrote: Hi List, I wonder why _FOSSIL_ file grows so fast. I did some little work with a clone of fossil source code repository (23MB) and over space of two days _FOSSIL_ reached 10MB. What gives? The _FOSSIL_ file contains (among other things) your stash and your undo history. What does sqlite3_analyzer _FOSSIL_ show you? Which tables are using the most space. Maybe it just needs to be vacuumed? All right. I compiled sqlite3_analyzer. The output is attached below. BTW, how do I vacuum a sqlite database?? I heard a lot about sqlite but I never used it before (terrible oversight). --Leo-- sqlite3_analyzer.out.bz2 Description: BZip2 compressed data ___ 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_ file grows large
On Wed, Feb 08, 2012 at 10:16:24AM -0500, Leo Razoumov wrote: The _FOSSIL_ file contains (among other things) your stash and your undo history. What does sqlite3_analyzer _FOSSIL_ show you? Which tables are using the most space. Maybe it just needs to be vacuumed? Looks to me like just needing a vacuum (most pages are free pages). sqlite3 _FOSSIL_ vacuum. ___ 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_ file grows large
2012/2/8 Lluís Batlle i Rossell vi...@viric.name On Wed, Feb 08, 2012 at 10:16:24AM -0500, Leo Razoumov wrote: The _FOSSIL_ file contains (among other things) your stash and your undo history. What does sqlite3_analyzer _FOSSIL_ show you? Which tables are using the most space. Maybe it just needs to be vacuumed? Looks to me like just needing a vacuum (most pages are free pages). sqlite3 _FOSSIL_ vacuum. Probably what happened is that you did some operation that created a large undo stack, which was stored in the _FOSSIL_ file. Then later, after the undo expired, that space was freed. If the space utilization is an issue for you, you can do this: sqlite3 _FOSSIL_ 'PRAGMA auto_vacuum=FULL; VACUUM;' And then the space will be automatically reclaimed in the future. I generally don't stress over a 10MB file on my 1TB disk drive, though... ___ 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] _FOSSIL_ file grows large
On Wed, Feb 8, 2012 at 11:05, Richard Hipp d...@sqlite.org wrote: Probably what happened is that you did some operation that created a large undo stack, which was stored in the _FOSSIL_ file. Then later, after the undo expired, that space was freed. If the space utilization is an issue for you, you can do this: sqlite3 _FOSSIL_ 'PRAGMA auto_vacuum=FULL; VACUUM;' And then the space will be automatically reclaimed in the future. I generally don't stress over a 10MB file on my 1TB disk drive, though... Richard, thanks for the tip. After vacuuming _FOSSIL_ size reduced from 9.7MB to 160KB. Speaking of disk usage. Here at ATT Labs I am running multiple virtual machines each having a shoe-string budget of 10 to 20GB disk space per machine. On that scale 10MB times number of open fossil repos is noticeable. --Leo-- ___ 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_ file grows large
On Wed, Feb 8, 2012 at 11:05, Richard Hipp d...@sqlite.org wrote: Probably what happened is that you did some operation that created a large undo stack, which was stored in the _FOSSIL_ file. Then later, after the undo expired, that space was freed. If the space utilization is an issue for you, you can do this: sqlite3 _FOSSIL_ 'PRAGMA auto_vacuum=FULL; VACUUM;' And then the space will be automatically reclaimed in the future. A cursory look into http://www.sqlite.org/pragma.html#pragma_auto_vacuum puzzles me: Auto-vacuuming is only possible if the database stores some additional information that allows each database page to be traced backwards to its referrer. Therefore, auto-vacuuming must be turned on before any tables are created. It is not possible to enable or disable auto-vacuum after a table has been created. Does VACUUM command also rebuild a database or it should be done separately? --Leo-- ___ 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_ file grows large
On Wed, Feb 8, 2012 at 11:53 AM, Leo Razoumov slonik...@gmail.com wrote: On Wed, Feb 8, 2012 at 11:05, Richard Hipp d...@sqlite.org wrote: Probably what happened is that you did some operation that created a large undo stack, which was stored in the _FOSSIL_ file. Then later, after the undo expired, that space was freed. If the space utilization is an issue for you, you can do this: sqlite3 _FOSSIL_ 'PRAGMA auto_vacuum=FULL; VACUUM;' And then the space will be automatically reclaimed in the future. A cursory look into http://www.sqlite.org/pragma.html#pragma_auto_vacuum puzzles me: Auto-vacuuming is only possible if the database stores some additional information that allows each database page to be traced backwards to its referrer. Therefore, auto-vacuuming must be turned on before any tables are created. It is not possible to enable or disable auto-vacuum after a table has been created. Does VACUUM command also rebuild a database or it should be done separately? The VACUUM command rebuilds the database. That's why you have to run VACUUM after doing PRAGMA auto_vacuum=FULL - to rebuild the database using the new auto_vacuum setting. Otherwise the PRAGMA will end up being a no-op. --Leo-- -- 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] make fossil up 'quiter'
hi there, fossil always reports the latest artifact ID and commit message whenever doing 'fossil up', even though actually there was no new check-in. for example: $ fossil up Autosync: http://www.fossil-scm.org/ Bytes Cards Artifacts Deltas Sent: 177 2 0 0 Received:2608 57 0 0 Total network traffic: 319 bytes sent, 1565 bytes received -- updated-to: 9b1d394a719f00f5a293612fe824e1a1fb1ed2e4 2012-02-08 03:04:23 UTC tags: trunk comment: Update the version number to 1.22 and begin entering change log information for the next release. (user: drh) this confuses me sometimes thinking there was a new check-in :[ wouldn't it be more natural not to print anything if the local check-out is exactly as the remote one? and have this repeating output as part of the --verbose output? what do you think? -f -- anarchy is better than no government at all. ___ 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] make fossil up 'quiter'
On Thu, Feb 09, 2012 at 01:55:01AM +0100, frantisek holop wrote: fossil always reports the latest artifact ID and commit message whenever doing 'fossil up', even though actually there was no new check-in. for example: $ fossil up Autosync: http://www.fossil-scm.org/ Bytes Cards Artifacts Deltas Sent: 177 2 0 0 Received:2608 57 0 0 Total network traffic: 319 bytes sent, 1565 bytes received -- updated-to: 9b1d394a719f00f5a293612fe824e1a1fb1ed2e4 2012-02-08 03:04:23 UTC tags: trunk comment: Update the version number to 1.22 and begin entering change log information for the next release. (user: drh) this confuses me sometimes thinking there was a new check-in :[ wouldn't it be more natural not to print anything if the local check-out is exactly as the remote one? and have this repeating output as part of the --verbose output? what do you think? While I agree with you on this topic, a relatively easy way to spot that there probably was a check-in is to look for non-zero count in the Deltas column in the Received row. Non-zero Artifacts count means that there were *some* changes, but they could relate to anything (bugs filed, their state changed, wiki changes etc), and non-zero Deltas indicates some files managed by fossil has been changed. Having said that, an output akin to Git's one would be way more helpful in the general case: the list of branches which received updates with symbolic indication about the kind of update occured. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
