[Monotone-devel] Re: Annoying behaviour with merge_into_dir

[Bruce Stephens]

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).)