[fossil-users] Newly introduced inconsistency
Hi all, I just saw the very recent checkin: [d59455e3f2] Leaf: Change 'checkin-count' to simply 'checkins' to keep the output aligned. While this seems to be an easy change, now the dbstat command outputs checkin-count while the info command outputs checkins. And because the dbstat outputs quite a few other counts as well, you cannot easily change it to checkins there as well as otherwise consistency between the entries of the dbstat output would be broken. If aligning the output is wanted, then I think you'll have to indent the second column of the other lines of the info output by one more space, then it nicely aligns even with checkin-count. Interestingly the two outputs produce different data (but that's another matter): $ fossil info | grep checkin checkin-count: 10 $ fossil dbstat | grep checkin checkin-count: 11 Greetings, Stefan -- Stefan Bellon ___ 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] Newly introduced inconsistency
On Thu, Jan 17, 2013 at 10:03 AM, Stefan Bellon sbel...@sbellon.de wrote: While this seems to be an easy change, now the dbstat command outputs checkin-count while the info command outputs checkins. And because the dbstat outputs quite a few other counts as well, you cannot easily change it to checkins there as well as otherwise consistency between the entries of the dbstat output would be broken. The dbstat command is brand new (1 week), meaning that we can still change anything it does without any compatibility issues - feel free to make suggestions. i don't mind making the changes, and the format of the dbstat output is more or less irrelevant to me. Easiest would be if you just paste in a mock-up of what you feel it should look like. Interestingly the two outputs produce different data (but that's another matter): $ fossil info | grep checkin checkin-count: 10 $ fossil dbstat | grep checkin checkin-count: 11 We discovered while adding dbstat that the /stat page and info command use an algorithm which apparently isn't 100% correct for checkin counts. i'm still investigating why this discrepancy exists (e.g. a bug or feature?), and once that's resolved we'll likely go back and change either info/stat or dbstat. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Newly introduced inconsistency
On Thu, 17 Jan 2013 10:26:29 +0100, Stephan Beal sgb...@googlemail.com wrote: On Thu, Jan 17, 2013 at 10:03 AM, Stefan Bellon sbel...@sbellon.de wrote: While this seems to be an easy change, now the dbstat command outputs checkin-count while the info command outputs checkins. And because the dbstat outputs quite a few other counts as well, you cannot easily change it to checkins there as well as otherwise consistency between the entries of the dbstat output would be broken. The dbstat command is brand new (1 week), meaning that we can still change anything it does without any compatibility issues - feel free to make suggestions. i don't mind making the changes, and the format of the dbstat output is more or less irrelevant to me. Easiest would be if you just paste in a mock-up of what you feel it should look like. Interestingly the two outputs produce different data (but that's another matter): $ fossil info | grep checkin checkin-count: 10 $ fossil dbstat | grep checkin checkin-count: 11 We discovered while adding dbstat that the /stat page and info command use an algorithm which apparently isn't 100% correct for checkin counts. i'm still investigating why this discrepancy exists (e.g. a bug or feature?), and once that's resolved we'll likely go back and change either info/stat or dbstat. currently I see with all my (~ 10...) repos -- _except_ with the fossil repo itself -- that the dbstat count is correct in the sense that it is identical to the number of entries visible in the timeline output (hoping/assuming that the latter does indeed show everything and is thus the ground truth). the `info' count is consistently below that number and in this sense wrong. however, in the fossil repo (as of today) I get these number of checkins: timeline: 4905 dbstat : 4906 info: 4860 i.e. in this single repo there is a difference of one between timeline and dbstat seemingly hinting at a specific bug either in the code or in the database I guess. regarding formatting of the output: I probably would label the corresponding `dbstat' entries like this: ... checkins: 4906 files: 749 across all branches wikipages: 24 (283 changes) tickets:990 (3137 changes) events: 4 tagchanges: 494 ... the `-count' is sort of redundant anyway. j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Newly introduced inconsistency
On Thu, Jan 17, 2013 at 12:24 PM, j. van den hoff veedeeh...@googlemail.com wrote: currently I see with all my (~ 10...) repos -- _except_ with the fossil repo itself -- that the dbstat count is correct in the sense that it is identical to the number of entries visible in the timeline output (hoping/assuming that the latter does indeed show everything and is thus the ground truth). the `info' count is consistently below that number and in this sense wrong. the difference between the two numbers differs in different repositories, but info/stat consistently show _lower_ values. They use a different query for the counting than dbstat does, and that query is apparently not 100% correct. Once we figure out why the mlink counts differ i'll feel confident enough to swap out the queries used by info/stat. however, in the fossil repo (as of today) I get these number of checkins: timeline: 4905 dbstat : 4906 info: 4860 i.e. in this single repo there is a difference of one between timeline and dbstat seemingly hinting at a specific bug either in the code or in the database I guess. The difference is repo-specific. In the fossil repo (old/large) the diff is relatively large. In my own repos (smaller/younger) the difference is smaller (anywhere from 1 to 10 or so). The difference we see here is due to using different counting queries, but whether or not this difference is due to a bug or is actually as-designed is not yet clear. For the near-term future they will differ, until i can figure out if the mlink table is being mis-used somewhere (i.e. if there's a bug). regarding formatting of the output: I probably would label the corresponding `dbstat' entries like this: ... checkins: 4906 files: 749 across all branches wikipages: 24 (283 changes) tickets:990 (3137 changes) events: 4 tagchanges: 494 ... the `-count' is sort of redundant anyway. Sounds good to me. i'll try to get that done tonight (i'm still at work). @Stefan: any objections to that? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] some questions about fossil-as-document-repo
Tomek Kott tkott.li...@outlook.com writes: Might I suggest the following two tools as better suited for this sort of endeavor? 1) Zotero - http://www.zotero.org/ This looks very interesting, and I can see where I might find a use for it myself in my personal life. Unfortunately, I don't think it will be a solution to my original problem since, as I mentioned, the documents I'm dealing with are being retained for legal reasons--which would be problematic for a service using a third-party server. In addition, whatever repository ends up being in place, more than a dozen people will need (read-only) access to it, and installing Zotero on everybody's PC is just one more thing for an already-stressed IT staff to keep up with (as opposed to one fossil binary on one server). 2) PDF XChange for free OCR - Fortunately, OCR is not an issue for us: the copiers/scanners we already have on contract have a fairly good OCR function built in. ___ 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] some questions about fossil-as-document-repo
C. Thomas Stover c...@thomasstover.com writes: Well if hardcopy means scanned paper (no ocr) then it sounds like a very large binary file set. I'm showing my ignorance, but does OCR matter in this case? We already have OCR capabilities, and I had intended to scan in the documents using it--because, why not, if you can? I didn't think to mention it in my original post to the list because I didn't think it would change the average file size significantly. ___ 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] some questions about fossil-as-document-repo
On Thu, 17 Jan 2013 07:55:09 -0600 Carson Chittom car...@wistly.net wrote: C. Thomas Stover c...@thomasstover.com writes: Well if hardcopy means scanned paper (no ocr) then it sounds like a very large binary file set. I'm showing my ignorance, but does OCR matter in this case? We already have OCR capabilities, and I had intended to scan in the documents using it--because, why not, if you can? I didn't think to mention it in my original post to the list because I didn't think it would change the average file size significantly. Well think about like this. In order to get a good enough detail for most purposes, these document scanners have somewhere around 600x600dpi resolution. At first you might think monochrome would work great (and it is still used sometimes with very high res modes), but in practice gray scale (or color) is really needed for handwriting, old paper, charts, and all sorts of applications. So the uncompressed bitmap for a single page can be quite big. So what about image/raster data compression? Well you either have loss-less (PNG) which works great for rendered vector graphics (diagrams, screen shots, etc), or loss-y (JPEG) which uses the characteristics of they way human vision processes colors to really work great for photographs. Neither one of these work that good for generic pieces of paper. What ends up happening is people just do an image resize to a smaller resolution, which (especially for handwriting) can be self defeating. On the other hand think how much space it takes for a page of UTF-8 text. Not much. So perfect OCR (which is a virtual impossibility) would take a 10+mb bitmap and convert it into a 2k text file. The solution today's technology uses is by using a container format like PDF where both images and text can be stored, the scanner software/firmware will OCR what it can and then mix that with little cropped images. This of course leads to the your mileage may very file sizes. -- C. Thomas Stover www.thomasstover.com ___ 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] some questions about fossil-as-document-repo
On Thu, 17 Jan 2013 18:53:43 +0100, C. Thomas Stover c...@thomasstover.com wrote: On Thu, 17 Jan 2013 07:55:09 -0600 Carson Chittom car...@wistly.net wrote: C. Thomas Stover c...@thomasstover.com writes: Well if hardcopy means scanned paper (no ocr) then it sounds like a very large binary file set. I'm showing my ignorance, but does OCR matter in this case? We already have OCR capabilities, and I had intended to scan in the documents using it--because, why not, if you can? I didn't think to mention it in my original post to the list because I didn't think it would change the average file size significantly. Well think about like this. In order to get a good enough detail for most purposes, these document scanners have somewhere around 600x600dpi resolution. At first you might think monochrome would work great (and it is still used sometimes with very high res modes), but in practice gray scale (or color) is really needed for handwriting, old paper, charts, and all sorts of applications. So the uncompressed bitmap for a single page can be quite big. So what about image/raster data compression? Well you either have loss-less (PNG) which works great for rendered vector graphics (diagrams, screen shots, etc), or loss-y (JPEG) which uses the characteristics of they way human vision processes colors to really work great for photographs. Neither one of these work that good for generic pieces of paper. What ends up happening is people just do an image resize to a smaller resolution, which (especially for handwriting) can be self defeating. On the other hand think how much space it takes for a page of UTF-8 text. Not much. So perfect OCR (which is a virtual impossibility) would take a 10+mb bitmap and convert it into a 2k text file. The solution today's technology uses is by using a container format like PDF where both images and text can be stored, the scanner software/firmware will OCR what it can and then mix that with little cropped images. This of course leads to the your mileage may very file sizes. just my 2c: there's also djvu http://djvu.org/ which provides astonishingly good compression for scanned documents, separation of layers, OCR etc. and there are converters from pdf to djvu around. otherwise I don't think that a SCM is really the suitable tool for your intended purpose (which I perceive as maintaining/backing up a list of versioned binary files): all SCMs that I know are not really good at handling big binary data sets (and delta-compression sure will not work that great...). so the repo will get real big in no time (and, for a DVCS, be copied to each and every user's account). but all the things the SCM offers (diffing, branching, merging) will _not_ work with binary data in a sensible way (I believe) and this also seems not to be what you need anyway. so the question is: why put it under revision control at all? the meta-information provided by the checkin-messages in the timeline alone would not be a sufficient reason in my view. I could imagine that a very basic solution (use the file system and maintain a logfile (or a (sqlite?) database (or fossil repo) of the metadata (file xyz.version_123 has this or that content and can be found here: and, possibly, as already suggested, an OCR dump) is more sensible. as said: just my 2c. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] some questions about fossil-as-document-repo
On Thu, 17 Jan 2013 19:48:20 +0100 Stephan Beal sgb...@googlemail.com wrote: FWIW: if the documents are having to be archived for legal reasons then the OCR versions are essentially only useful for convenience in searching, and not for legal purposes. that's good information to know On Thu, 17 Jan 2013 19:51:58 +0100 j. van den hoff veedeeh...@googlemail.com wrote: just my 2c: there's also djvu http://djvu.org/ which provides astonishingly good compression for scanned documents, separation of layers, OCR etc. always good to find new things otherwise I don't think that a SCM is really the suitable tool for your intended purpose (which I perceive as maintaining/backing up a list of versioned binary files): all SCMs that I know are not really good at handling big binary data sets (and delta-compression sure will not work that great...). so the repo will get real big in no time yep. I've tried this a number of ways with photos, and it just didn't work out. Although I have stored large number of mostly text-based pdf's in scm before for lack of better tool, and it wasn't the end of the world. Someday someone will create a tool to fill in the gap. Sort of a DVCS style metadata logging and control facility to a rsync style technology. Kind of like some of the interpretations of distributed file system back in the plan 9 lineage of thought for instance. C. Thomas Stover www.thomasstover.com ___ 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] Newly introduced inconsistency
On Thu, 17 Jan, Stephan Beal wrote: @Stefan: any objections to that? No, that's fine with me. My reasoning for the -count was to be able to easily grep out all the counts if one is interested in just the counts from the dbstat page: $ fossil dbstat -R test.fossil | grep count artifact-count: 24 (stored as 6 full text and 18 delta blobs) checkin-count: 11 file-count: 5 across all branches wikipage-count: 0 (0 changes) ticket-count: 0 (0 changes) event-count:0 tagchange-count:0 This does not work if they do not have the common suffix -count. But that's no big problem for me. I just tend to put some thinking into proper names and the implications this choice may have. Greetings, Stefan -- Stefan Bellon ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] sqlite errors after reinstalling fossil
Hello all; I'm seeing errors like this. % fossil init blah fossil: SQLITE_IOERR: statement aborts at 1: [BEGIN EXCLUSIVE] disk I/O error fossil: SQLITE_IOERR: disk I/O error fossil: disk I/O error If you have recently updated your fossil executable, you might need to run fossil all rebuild to bring the repository schemas up to date. % uname -a FreeBSD awarnach.mathstat.dal.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERI C amd64 I just upgraded to FreeBSD 9.1 and removed all ports. When I reinstalled fossil via the FreeBSD port I had these problems. Thanks for any suggestions, Joseph ___ 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] sqlite errors after reinstalling fossil
On Thu, Jan 17, 2013 at 4:13 PM, Joseph Mingrone j...@ftfl.ca wrote: Hello all; I'm seeing errors like this. % fossil init blah fossil: SQLITE_IOERR: statement aborts at 1: [BEGIN EXCLUSIVE] disk I/O error fossil: SQLITE_IOERR: disk I/O error fossil: disk I/O error I just upgraded to FreeBSD 9.1 and removed all ports. When I reinstalled fossil via the FreeBSD port I had these problems. Thanks for any suggestions, Have you tried compiling Fossil yourself from sources? (It isn't hard.) -- 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] sqlite errors after reinstalling fossil
On Thu, Jan 17, 2013 at 5:25 PM, Richard Hipp d...@sqlite.org wrote: Have you tried compiling Fossil yourself from sources? (It isn't hard.) Yes. Same result. Joseph ___ 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] sqlite errors after reinstalling fossil
I should also mention that everything seems to work fine when I run fossil as root, but not with sudo. It doesn't appear to be anything specific to my environment because the same problem occurs with other users on the box. Joseph ___ 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] sqlite errors after reinstalling fossil
On Thu, Jan 17, 2013 at 4:35 PM, Joseph Mingrone j...@ftfl.ca wrote: I should also mention that everything seems to work fine when I run fossil as root, but not with sudo. It doesn't appear to be anything specific to my environment because the same problem occurs with other users on the box. And, you say, it was working fine on the previous version of FreeBSD? What version did you upgrade from? -- 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] sqlite errors after reinstalling fossil
One change I made when I upgraded the box was that I set home directories to be nfs mounted from a storage server. I'm using the automount daemon to do the mounting. Before home directories were local. To test if this was causing a problem I created a new user with a local home directory. This new user can run fossil without problems. The root user also has a local home directory. Joseph ___ 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] sqlite errors after reinstalling fossil
On Thu, Jan 17, 2013 at 5:46 PM, Richard Hipp d...@sqlite.org wrote: And, you say, it was working fine on the previous version of FreeBSD? What version did you upgrade from? It was working fine on the previous version, which was 8.3. It's also working fine on other machines running 9.1-RELEASE, but with local home directories. ___ 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] sqlite errors after reinstalling fossil
On Thu, Jan 17, 2013 at 4:46 PM, Joseph Mingrone j...@ftfl.ca wrote: One change I made when I upgraded the box was that I set home directories to be nfs mounted from a storage server. I'm using the automount daemon to do the mounting. Before home directories were local. To test if this was causing a problem I created a new user with a local home directory. This new user can run fossil without problems. The root user also has a local home directory. That's a good clue. It makes me think this is probably an NFS problem, perhaps related to posix advisory locking and your NFS implementations' inability to support it. Try setting: export FOSSIL_VFS=unix-dotfile or export FOSSIL_VFS=unix-none Then run Fossil (as a normal) user and see if that fixes the problem. Please let me know what happens -- 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] sqlite errors after reinstalling fossil
On 01/17/13 16:46, Joseph Mingrone wrote: One change I made when I upgraded the box was that I set home directories to be nfs mounted from a storage server. I'm using the automount daemon to do the mounting. Before home directories were local. To test if this was causing a problem I created a new user with a local home directory. This new user can run fossil without problems. The root user also has a local home directory. Wild guess: are you running your rpc services, lockd and statd amongst them? (server? client?) I'd expect sqlite to trip over not being able to (f)lock a file... -Martin ___ 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] Newly introduced inconsistency
On Thu, 17 Jan 2013 13:45:36 +0100, Stephan Beal sgb...@googlemail.com wrote: however, in the fossil repo (as of today) I get these number of checkins: timeline: 4905 dbstat : 4906 info: 4860 i.e. in this single repo there is a difference of one between timeline and dbstat seemingly hinting at a specific bug either in the code or in the database I guess. The difference is repo-specific. In the fossil repo (old/large) the diff is relatively large. In my own repos (smaller/younger) the difference is there is an additionally specific problem (not seen with other repos) that the number of `timeline' entries is off by one relative to the `dbstat' opinion of the number of checkins. smaller (anywhere from 1 to 10 or so). The difference we see here is due to using different counting queries, but whether or not this difference is due to a bug or is actually as-designed is not yet clear. For the near-term future they will differ, until i can figure out if the mlink table is being mis-used somewhere (i.e. if there's a bug). -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] sqlite errors after reinstalling fossil
On Thu, Jan 17, 2013 at 5:52 PM, Richard Hipp d...@sqlite.org wrote: That's a good clue. It makes me think this is probably an NFS problem, perhaps related to posix advisory locking and your NFS implementations' inability to support it. Try setting: export FOSSIL_VFS=unix-dotfile or export FOSSIL_VFS=unix-none Setting FOSSIL_VFS didn't help. The storage server is running zfs. When I created the filesystem for the home directories I turned off access times. Here is the full command I used to create the file system: zfs create -o atime=off -o compression=on -o -o sharenfs=maproot=root,network 192.168.0.0,mask 255.255.255.0 tank/home. I just created a new zfs filesystem on the server but I didn't turn off the access times. I then created a new user whose home directory was set to this new file system. This user can run fossil without any problems. I put access times a back on for tank/home (the filesystem all other users except root have as their home directory), but those users still have the fossil errors. On Thu, Jan 17, 2013 at 5:58 PM, Martin S. Weber martin.we...@nist.gov wrote: Wild guess: are you running your rpc services, lockd and statd amongst them? (server? client?) Both the client are server are running rpcbind and mountd. Joseph ___ 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] sqlite errors after reinstalling fossil
On Thu, Jan 17, 2013 at 4:13 PM, Joseph Mingrone j...@ftfl.ca wrote: Hello all; I'm seeing errors like this. % fossil init blah fossil: SQLITE_IOERR: statement aborts at 1: [BEGIN EXCLUSIVE] disk I/O error fossil: SQLITE_IOERR: disk I/O error fossil: disk I/O error What does the following command show? fossil init blah --sqltrace -- 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] sqlite errors after reinstalling fossil
On Thu, Jan 17, 2013 at 5:11 PM, Joseph Mingrone j...@ftfl.ca wrote: On Thu, Jan 17, 2013 at 5:52 PM, Richard Hipp d...@sqlite.org wrote: That's a good clue. It makes me think this is probably an NFS problem, perhaps related to posix advisory locking and your NFS implementations' inability to support it. Try setting: export FOSSIL_VFS=unix-dotfile or export FOSSIL_VFS=unix-none Setting FOSSIL_VFS didn't help. Please try again using the patch to Fossil I just now checked in: http://www.fossil-scm.org/fossil/info/7536c6aea5 The storage server is running zfs. When I created the filesystem for the home directories I turned off access times. Here is the full command I used to create the file system: zfs create -o atime=off -o compression=on -o -o sharenfs=maproot=root,network 192.168.0.0,mask 255.255.255.0 tank/home. I just created a new zfs filesystem on the server but I didn't turn off the access times. I then created a new user whose home directory was set to this new file system. This user can run fossil without any problems. I put access times a back on for tank/home (the filesystem all other users except root have as their home directory), but those users still have the fossil errors. On Thu, Jan 17, 2013 at 5:58 PM, Martin S. Weber martin.we...@nist.gov wrote: Wild guess: are you running your rpc services, lockd and statd amongst them? (server? client?) Both the client are server are running rpcbind and mountd. Joseph ___ 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] sqlite errors after reinstalling fossil
On Thu, Jan 17, 2013 at 6:18 PM, Richard Hipp d...@sqlite.org wrote: fossil init blah --sqltrace % fossil init blah --sqltrace fossil: SQLITE_IOERR: statement aborts at 1: [BEGIN EXCLUSIVE] disk I/O error fossil: SQLITE_IOERR: disk I/O error fossil: disk I/O error If you have recently updated your fossil executable, you might need to run fossil all rebuild to bring the repository schemas up to date. ___ 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] sqlite errors after reinstalling fossil
The test user I created, whose home directory is set to the new filesystem with access times turned on, is also having the sqlite problems 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] sqlite errors after reinstalling fossil
This problem doesn't look much like an issue with fossil itself. Perhaps trying a filesystem test suite would give you some hints as to the root cause? Google provided this link that might be a good starting point: http://nfsv4.bullopensource.org/doc/testing_tools.php Do things such as a kernel compile, video editing or other disk intensive tasks work fine? On Thu, Jan 17, 2013 at 3:32 PM, Joseph Mingrone j...@ftfl.ca wrote: The test user I created, whose home directory is set to the new filesystem with access times turned on, is also having the sqlite problems now. ___ 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] sqlite errors after reinstalling fossil
On Thu, Jan 17, 2013 at 6:24 PM, Richard Hipp d...@sqlite.org wrote: Please try again using the patch to Fossil I just now checked in: http://www.fossil-scm.org/fossil/info/7536c6aea5 It didn't compile for me. ... cc -g -O2 -DHAVE_AUTOCONFIG_H -I. -I./src -Ibld -o bld/db.o -c bld/db_.c ./src/db.c: In function 'db_open_config': ./src/db.c:819: error: 'Global' has no member named 'zConfigDbType' ./src/db.c:823: error: 'Global' has no member named 'zConfigDbType' ./src/db.c: In function 'db_close': ./src/db.c:1193: error: 'Global' has no member named 'zConfigDbType' ./src/db.c: In function 'db_swap_connections': ./src/db.c:1669: error: 'Global' has no member named 'zConfigDbType' ./src/db.c:1671: error: 'Global' has no member named 'zConfigDbType' gmake: *** [bld/db.o] Error 1 ___ 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] sqlite errors after reinstalling fossil
2013/1/18 Joseph Mingrone j...@ftfl.ca: On Thu, Jan 17, 2013 at 6:24 PM, Richard Hipp d...@sqlite.org wrote: Please try again using the patch to Fossil I just now checked in: http://www.fossil-scm.org/fossil/info/7536c6aea5 It didn't compile for me. ... cc -g -O2 -DHAVE_AUTOCONFIG_H -I. -I./src -Ibld -o bld/db.o -c bld/db_.c ./src/db.c: In function 'db_open_config': ./src/db.c:819: error: 'Global' has no member named 'zConfigDbType' ./src/db.c:823: error: 'Global' has no member named 'zConfigDbType' ./src/db.c: In function 'db_close': ./src/db.c:1193: error: 'Global' has no member named 'zConfigDbType' ./src/db.c: In function 'db_swap_connections': ./src/db.c:1669: error: 'Global' has no member named 'zConfigDbType' ./src/db.c:1671: error: 'Global' has no member named 'zConfigDbType' gmake: *** [bld/db.o] Error 1 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users Can you host somewhere the file.out created by truss -o file.out fossil init bla ? regards, Bapt (maintainer of fossil for FreeBSD) ___ 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] sqlite errors after reinstalling fossil
Hello Baptiste; On Thu, Jan 17, 2013 at 7:02 PM, Baptiste Daroussin baptiste.darous...@gmail.com wrote: Can you host somewhere the file.out created by truss -o file.out fossil init bla ? Sure. http://gly.ath.cx/misc/file.out Joseph ___ 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] sqlite errors after reinstalling fossil
On Thu, Jan 17, 2013 at 7:03 PM, Richard Hipp d...@sqlite.org wrote: I don't know why not... Did you start from fresh sources? What did you do to get the error below? Apparently I didn't start from fresh sources or I messed something else up. After... tar -xf tar -xvf fossil-src-20121022124804.tar.gz cd fossil-src-20121022124804/src/ fetch 'http://www.fossil-scm.org/fossil/raw/src/db.c?name=1b058e27e61edc91b7a5ce404ac5add09328b16d' cd .. ./configure gmake It compiles fine. But, in the same directory I just did: fossil init blah and I get the same error. Joseph ___ 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] sqlite errors after reinstalling fossil
On Thu, Jan 17, 2013 at 7:21 PM, Joseph Mingrone j...@ftfl.ca wrote: fossil init blah Make that ./fossil init blah and I get the same error. ___ 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] sqlite errors after reinstalling fossil
2013/1/18 Joseph Mingrone j...@ftfl.ca: On Thu, Jan 17, 2013 at 7:03 PM, Richard Hipp d...@sqlite.org wrote: I don't know why not... Did you start from fresh sources? What did you do to get the error below? Apparently I didn't start from fresh sources or I messed something else up. After... tar -xf tar -xvf fossil-src-20121022124804.tar.gz cd fossil-src-20121022124804/src/ fetch 'http://www.fossil-scm.org/fossil/raw/src/db.c?name=1b058e27e61edc91b7a5ce404ac5add09328b16d' cd .. ./configure gmake It compiles fine. But, in the same directory I just did: fossil init blah and I get the same error. Joseph ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users Your failure is the following: fcntl(4,F_SETLK,0x7fffcca0) ERR#45 'Operation not supported' Something is wrong about your nfs setup imho regards, Bapt ___ 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] sqlite errors after reinstalling fossil
On Thu, Jan 17, 2013 at 6:23 PM, Baptiste Daroussin baptiste.darous...@gmail.com wrote: 2013/1/18 Joseph Mingrone j...@ftfl.ca: On Thu, Jan 17, 2013 at 7:03 PM, Richard Hipp d...@sqlite.org wrote: I don't know why not... Did you start from fresh sources? What did you do to get the error below? Apparently I didn't start from fresh sources or I messed something else up. After... tar -xf tar -xvf fossil-src-20121022124804.tar.gz cd fossil-src-20121022124804/src/ fetch ' http://www.fossil-scm.org/fossil/raw/src/db.c?name=1b058e27e61edc91b7a5ce404ac5add09328b16d ' cd .. ./configure gmake It compiles fine. But, in the same directory I just did: fossil init blah and I get the same error. Joseph ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users Your failure is the following: fcntl(4,F_SETLK,0x7fffcca0) ERR#45 'Operation not supported' Something is wrong about your nfs setup imho The FOSSIL_VFS=unix-none environment variable setting to Fossil should prevent Fossil from using posix advisory locking. That should work around the NFS problem shown above. I do not know why that part isn't working. regards, Bapt ___ 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] some questions about fossil-as-document-repo
I don't think Fossil is the right tool for this, take a look at Calibre (http://calibre-ebook.com/) as an Open Source document management system, not just an e-book reader. Calibre manages your e-book/book/PDF collection and can sort the books in your library by: Title, Author, Date added, Date published, Size, Rating, Series, etc. In addition, it supports extra searchable metadata: * Tags: A flexible system for categorizing your collection however you like * Comments: A long form entry that you can use for book description, notes, reviews, etc * User fields, so you can have a revision code, or you could include the revision code in the title (probably better), for example You can easily search your collection for a particular book. Calibre supports searching any and all of the fields mentioned above. You can construct advanced search queries by clicking the helpful Advanced search button to the left of the search bar. You can export arbitrary subsets of your collection to your hard disk arranged in a fully customizable folder structure. For group access Calibre has a built-in web server that allows you to access your collection using a simple browser from any computer anywhere in the world. It can also email your books and downloaded news to you automatically. It has support for mobile devices, so you can browse your collection and download books from your smartphone, Kindle, etc. One point to note is that systems files the documents by Author/Title on the hard disk, this is fixed and you cannot change this. However, this is not as inflexible as it sounds, because the Author could be a Client, Journal, or whatever you wish. I use Calibre for my technical library with over 8000 technical papers and have found it an indispensable tool for managing and finding information. -- Regards, David Baxendale Message: 5 Date: Wed, 16 Jan 2013 19:31:59 -0500 From: Tomek Kotttkott.li...@outlook.com To: Fossil SCM user's discussionfossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] some questions about fossil-as-document-repo Message-ID:col002-w50fb60fc6525b15acfa82af3...@phx.gbl Content-Type: text/plain; charset=iso-8859-1 Might I suggest the following two tools as better suited for this sort of endeavor? 1) Zotero -http://www.zotero.org/ 2) PDF XChange for free OCR -http://www.tracker-software.com/product/pdf-xchange-viewer The first is a good pdf sorter that can work in stand alone mode. You can also tag things with metadata / tags / years etc. The second is a free PDF reader that I use instead of Adobe, and recently it was updated with free OCR. In my use the OCR has actually been very good. It can place the text of the PDF behind the image, so you can select the text while viewing the original scanned copy. I do this for bills and such at home. I personally don't see fossil as the right tool for a document repo. Tomek Date: Wed, 16 Jan 2013 16:33:09 -0600 From:c...@thomasstover.com To:fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] some questions about fossil-as-document-repo On Wed, 16 Jan 2013 16:11:49 -0600 Carson Chittomcar...@wistly.net wrote: Yes, basically, it's the probably should save for later need--mostly for legal reasons. Currently all this is in hardcopy, as I mentioned, the volume of which has reached such a level as to be simply impenetrable; part of the reason for putting them as images into a repository is simply to organize them. Well if hardcopy means scanned paper (no ocr) then it sounds like a very large binary file set. That sort of thing quickly gets up larger than most photo collections. The logic of the concept is sound. Report back on how it goes in practice. -- C. Thomas Stover www.thomasstover.com ___ 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] some questions about fossil-as-document-repo
On 01/17/2013 02:29 PM, Carson Chittom wrote: But these are not legal documents in the sense I think you mean--contracts, etc. Our lawyer keeps those. Our use case is more of a question of one of our staff being able to find something that documents that previously we did x in case y, so if we get case z we should also do x if y = z, Then OCR is what you want and any OCR typos can be caught by the reader. Don't store the images. Then the diffs and compressions *will* work in the SCM. On 01/17/2013 07:33 PM, David Baxendale (GMail - Singapore) wrote: Calibre manages your e-book/book/PDF collection and can sort the books in your library by: Title, Author, Date added, Date published, Size, Rating, Series, etc. In addition, it supports extra searchable metadata: * Tags: A flexible system for categorizing your collection however you like * Comments: A long form entry that you can use for book description, notes, reviews, etc * User fields, so you can have a revision code, or you could include the revision code in the title (probably better), for example Calibre does sound good. I'm going to look into it for managing datasheets used in electronics designs. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
