|
From: | Markus Schiltknecht |
Subject: | Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?) |
Date: | Tue, 29 Aug 2006 09:28:51 +0200 |
User-agent: | Thunderbird 1.5.0.5 (X11/20060812) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |