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
On Thu, Jan 17, 2013 at 10:03 AM, Stefan Bellon 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 "
On Thu, 17 Jan 2013 10:26:29 +0100, Stephan Beal
wrote:
On Thu, Jan 17, 2013 at 10:03 AM, Stefan Bellon
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
On Thu, Jan 17, 2013 at 12:24 PM, j. van den hoff 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
Tomek Kott 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 sol
"C. Thomas Stover" 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, i
On Thu, 17 Jan 2013 07:55:09 -0600
Carson Chittom wrote:
> "C. Thomas Stover" 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,
On Thu, Jan 17, 2013 at 6:53 PM, C. Thomas Stover wrote:
> 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.
>
FWIW: if the documents are having t
On Thu, 17 Jan 2013 18:53:43 +0100, C. Thomas Stover
wrote:
On Thu, 17 Jan 2013 07:55:09 -0600
Carson Chittom wrote:
"C. Thomas Stover" 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 matt
On Thu, 17 Jan 2013 19:48:20 +0100
Stephan Beal 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
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:
Stephan Beal writes:
> On Thu, Jan 17, 2013 at 6:53 PM, C. Thomas Stover
> wrote:
>
>> 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.
>>
>
>
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
On Thu, Jan 17, 2013 at 4:13 PM, Joseph Mingrone 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 Fre
On Thu, Jan 17, 2013 at 5:25 PM, Richard Hipp 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/c
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 maili
On Thu, Jan 17, 2013 at 4:35 PM, Joseph Mingrone 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,
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
On Thu, Jan 17, 2013 at 5:46 PM, Richard Hipp 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 lo
On Thu, Jan 17, 2013 at 4:46 PM, 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
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
On Thu, 17 Jan 2013 13:45:36 +0100, Stephan Beal
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 specif
On Thu, Jan 17, 2013 at 5:52 PM, Richard Hipp 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
>
>
On Thu, Jan 17, 2013 at 4:13 PM, Joseph Mingrone 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 followin
On Thu, Jan 17, 2013 at 5:11 PM, Joseph Mingrone wrote:
> On Thu, Jan 17, 2013 at 5:52 PM, Richard Hipp 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.
> >
On Thu, Jan 17, 2013 at 6:18 PM, Richard Hipp 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 exec
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/mailma
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 co
On Thu, Jan 17, 2013 at 10:59 PM, j. v. d. hoff
wrote:
> 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.
Thanks for the tip.
Reminder to self: check if shu
On Thu, Jan 17, 2013 at 6:38 PM, Matt Welland wrote:
> Do things such as a kernel compile, video editing or other disk intensive
> tasks work fine?
It's only been a few weeks, but all IO seems fine. I did some IO
testing with IOR (http://sourceforge.net/projects/ior-sio/) and it
looked OK.
% ./
On Thu, Jan 17, 2013 at 6:24 PM, Richard Hipp 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
2013/1/18 Joseph Mingrone :
> On Thu, Jan 17, 2013 at 6:24 PM, Richard Hipp 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 -Ibl
On Thu, Jan 17, 2013 at 6:00 PM, Joseph Mingrone wrote:
> On Thu, Jan 17, 2013 at 6:24 PM, Richard Hipp 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.
>
I don't know why not.
Hello Baptiste;
On Thu, Jan 17, 2013 at 7:02 PM, Baptiste Daroussin
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
On Thu, Jan 17, 2013 at 7:03 PM, Richard Hipp 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
On Thu, Jan 17, 2013 at 7:21 PM, Joseph Mingrone 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/listin
2013/1/18 Joseph Mingrone :
> On Thu, Jan 17, 2013 at 7:03 PM, Richard Hipp 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 -
On Thu, Jan 17, 2013 at 6:23 PM, Baptiste Daroussin <
baptiste.darous...@gmail.com> wrote:
> 2013/1/18 Joseph Mingrone :
> > On Thu, Jan 17, 2013 at 7:03 PM, Richard Hipp wrote:
> >> I don't know why not... Did you start from fresh sources? What did
> you do
> >> to get the error below?
> >
> >
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, D
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 w
40 matches
Mail list logo
