[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: Annoying behaviour with merge_into_dir
From: |
Bruce Stephens |
Subject: |
[Monotone-devel] Re: Annoying behaviour with merge_into_dir |
Date: |
Thu, 15 Feb 2007 18:53:23 +0000 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.93 (gnu/linux) |
Timothy Brownawell <address@hidden> writes:
[...]
> Yes, this is how it's supposed to be.
>
> In most cases (whenever the parents have a common ancestor), the two
> halves of a merge revision are redundant. Only storing one half could
> save some space, but would make some operations slower. I don't think
> anyone has seen a need to look into whether this is a sensible thing to
> do yet... do you know what percentage of space this could actually save
> you? You can get an upper bound from 'db info' and the "revisions" and
> "total" byte counts (this gives that revisions are 12% of total for a db
> of off.net/'*').
bytes:
full rosters : 14560041
roster deltas : 4767798
full files : 217661720
file deltas : 46087446
revisions : 24226683
cached ancestry : 475640
certs : 6950528
heights : 487928
total : 315217784
So, not too bad, less than 10% (5448 revisions). However, if I remove
the revisions in the branches I'm worried about, leaving 5408
revisions:
bytes:
full rosters : 14560041
roster deltas : 4767798
full files : 217661720
file deltas : 46087446
revisions : 6231759
cached ancestry : 469560
certs : 6905113
heights : 485888
total : 297169325
And that's what's really bothering me: it breaks my assumption that a
commit costs something roughly proportional to the change I'm making.
IIUC, in this sort of scenario, each commit will cost me that, plus a
cost proportional to the size of all the things I'm not changing,
including stuff that I'm rarely going to be changing (because I used
merge_into_dir to include it, just for convenience).
(In normal use, I guess I'd expect the size of the revisions to be
quite a bit bigger than this (more like the 12% or so you noted).
Mine are small because this is generated from Tailor from CVS via
subversion, so most of them are just straight branches, with a small
proportion of merges (from propagates I've made to my working
branches).)