Timothy Brownawell <[EMAIL PROTECTED]> 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).) _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
