Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)

[Nathaniel Smith]

On Mon, Aug 28, 2006 at 02:28:36PM +0200, Markus Schiltknecht wrote:
> Bruce Stephens wrote:
> >That doesn't make sense without specifying the file.  CVS versions
> >files independently, so there is no single CVS revision for a coherent
> >checkout (almost always, anyway).
> 
> Sorry, I should have made that clearer. I meant to store something like:
> 
> file_foo.txt 1.75
> file_bar.txt 1.9
> TODO 1.1
> README 1.5
> 
> per revision. Additionally one could save infos like: 'all CVS commits 
> were between 27/08/2006 15:42:13 and 27/08/2006 15:42:19' or even:
> 'this revision overlaps in CVS with MTN revision 359a3f2...'
>
> IMHO saving such information per revision make sense from the end-user 
> perspective (i.e. is more or less human-readable). An cvsimport could 
> theoretically be taught to parse this information. (I'm not sure if that 
> is sufficient information for a resync, though).

The problem is that the version number for a full CVS tree is really
really long.

E.g., if monotone's tree has ~1800 files, and if it were created by
importing from cvs, writing down such a cert would take on the order
of 64kB.  (Calculated by 'mtn ls known | wc -c' to get filename
lengths, plus some fudge for the version numbers.)  Certs are not
delta compressed nor, in the current implementation, even gzipped.
My database has ~7000 revisions in it.  If every revision in it had
such a cert on it (again, as if it were imported from CVS), then that
would come to ~450 megabytes of certs, so almost 7 times more data
than the entire history combined.

So, you see how some sort of delta compression in necessitated, which
is what gets us into this whole mess.

-- Nathaniel

-- 
"Lull'd in the countless chambers of the brain,
Our thoughts are link'd by many a hidden chain:
Awake but one, and lo! what myriads rise!
Each stamps its image as the other flies"
  -- Ann Ward Radcliffe, The Mysteries of Udolpho