monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] No file-based commands yet?


From: graydon hoare
Subject: Re: [Monotone-devel] No file-based commands yet?
Date: 10 Nov 2003 22:22:33 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Kevin Smith <address@hidden> writes:

> It appears that there is currently no way to:
> 
> - List the revision history for a just one certain file
> - Perform a diff of a single file, either between my workspace copy
> and the head in the database, nor between two revisions in the database

no, unfortunately I haven't written either of these yet. they're not
impossible, just.. there'a lot to do :)

patches implementing them would certainly be welcome (or if you can
set up a monotone depot and point me at it, I'll fetch such changes
in). or.. even if you want to just add such things as feature request
entries in the BTS, that'd be great. then I'll be much more likely to
remember to do them.

> Also, I notice you recently increased the maximum sqlite row
> size. Would that fix this error that I saw when trying an initial
> checkin of a fresh project?

yeah, I bumped the size to 16mb. it used to be 1mb, so you might have
hit it. I've been playing with a few sqlite constants recently, and
having very interesting results. I'll be doing a page size increase in
between 0.8 and 0.9, which will require a dump & load, but in the
tests I've done it cuts space use quite dramatically.

> What does the new 16 mb limit actually mean? Does that mean that
> monotone wouldn't work for certain types of projects? Or would there
> always be certain checkins that would fail?

it is a limit on individual items, not the project as a whole. you
can't store any individual cert, file, manifest or delta larger than
16mb, gzipped and base64 encoded. the database itself works up to 2^41
bytes (I've personally imported and tested ~2gb databases at home)

judging from the comment in the sqlite sources, the 16mb is derived
from the maximum addressable overflow page number 16448 (2^14 - 64)
times the size of a page, normally 1020 (2^10 - 4 bytes for a "next"
pointer), plus the base size 238 (1024 / 4 + some header) of a btree
cell.

I'm planning on upping the page size, though, to something in the
range of 2^13 to 2^16 bytes, which would presumably give us another
factor of 8 .. 64 in maximum size (128mb .. 1gb), assuming I interpret
the comments correctly.

but, even then, your gut feeling is right: there are some checkins you
really can't get away with. no storing multi-gigabyte .vob files. at
least, not without making the page size much larger; I'm not sure if
there's a *technical* limit on its size, but I'd like to optimize for
the case of storing, say, ~1k patches and ~50k files. source code is
the target.

-graydon







reply via email to

[Prev in Thread] Current Thread [Next in Thread]