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

[Markus Schiltknecht]

Nathaniel Smith wrote:
> 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.

Yes, thank you for your explanation.

If we store the original RCS version as a file attribute, how can the 
end-user query what CVS files he got with a given MTN revision? Where 
could we save 'per revision' information? (The '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...' things)?

And can we somehow ensure, that the file attribute gets deleted after 
the first MTN commit? It seems irritating to have the latest RCS version 
attached to all files after that.

(My understanding is that such information would much better fit into a 
per revision cert, instead of file attributes, which sounds somewhat 
like a hack. But I guess compressing or even delta-compressing certs is 
not an option, huh?)

Regards

Markus