I've been thinking about piece caches lately, as a possible next step
in my quest to trim all the fat off our common code paths. The idea
of a piece cache comes when doing reconstruction of xdelta chains.
What we do now is cache recently accessed full-texts, but this is sort
of silly; the way
Timothy Brownawell schrieb:
*) The information attachment is meant to be space efficient (xdiff
encoded where possible) and uses both special files .mtn-syn-* and
certificates where it has to attach information to an already present
revision.
Why is there a need for this? It seems like it
Nathaniel Smith wrote:
Umm, Derek? 'automate' is where we're supposed to actually care about
compatibility -- that we happened to tweak the changeset format is
fine, but I'm sure the connection between that and the inventory
output format is not obvious to people implementing 3rd-party tools,
In revision d5c243284c11d56d314180296b17666a8ee221a7, numbered format
specifiers appear in cmd_ws_commit.cc:
* cmd_ws_commit.cc (CMD(commit)): Use positional format
to ease translation.
--- cmd_ws_commit.ccf24529cd245deb0002fdaa15f0f8b6d1e9d0e338
+++ cmd_ws_commit.cc
What does this I/O failure message mean? Push fails but poll works fine.
Cheers,
Shaun
$ mtn push
mtn: connecting to venge.net
mtn: finding items to synchronize:
mtn: certificates | keys | revisions
mtn: 19,969 | 33 | 6,617
mtn: bytes in | bytes out | certs out | revs out
mtn:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wonder: why the sources are only available as .tar.gz?
Using .tar.bz2 they compress down to 3.5 MiB instead of 4.6 MiB.
If the choice was mine, I'd also put on the server a detached GPG
signature of the file.
It can't hurt and I can actually verify
On Mon, Jul 31, 2006 at 09:07:58PM +0200, Lapo Luchini wrote:
I wonder: why the sources are only available as .tar.gz?
Using .tar.bz2 they compress down to 3.5 MiB instead of 4.6 MiB.
Tradition? (Does it matter?)
If the choice was mine, I'd also put on the server a detached GPG
signature of
On 7/31/06, Graydon Hoare [EMAIL PROTECTED] wrote
Zack Weinberg wrote:
However, what it does have is references to the database and
lua_hooks objects.
Ownership as sub-objects, or pointers, or C++ references?
Presently, -references, like this:
struct workspace {
...
workspace(database
Zack Weinberg wrote:
now is that a small minority of app.work.foo() calls take an app_state
reference and there's no rhyme nor reason to which of them it is; thus
the thought that it might be better to put a reference to the entire
app_state into the workspace object. [It would not help to
