On Mon, Jan 12, 2015 at 12:43:28PM +0100, Stephan Beal wrote: > > However, Fossil puts both filenames (which are content), and the indicator > > of whether delta compression is used, in the same structure, and changes > > that structure depending on whether delta compression is used, and the hash > > of that full structure is used as a content-UUID in future content. This is > > the problem, just like changing a blob's UUID depending on whether the blob > > is gzip-compressed would be a problem. > > > > Correct. To be fair: B-cards (manifest/delta compression) were added long > after the initial manifest design, and had to be done in a compatible > manner.
Actually, incorrect. The manifest does *not* record whether delta compression is used or not. That is recorded in the database and an implementation detail of the blob table. The manifest only stores *base* manifest references, which is a partial version of full incremental manifest. The advantage of the choosen schema is that to compute the full manifest of a given version, only two "partial" manifests need to be processed -- the manifest itself and the referenced base version. The downside is that for larger trees, the incremental manifests can still sum up to quite a bit text, which makes rebuild very slow. Joerg _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
