On Wed, Nov 22, 2017 at 07:01:31PM -0500, Richard Hipp wrote: > > (2) Store true differential manifests. > > I'm thinking that Fossil-NG will probably do like Git and store > separate artifacts holding the content of each directory. (Git calls > these "Tree Objects"). I need to do more research, but I'm thinking > that for most check-ins, only one or two directory artifacts will > actually change, even if there are dozens or hundreds (or multiple > thousands as in NetBSD) of directory artifacts in a single check-out.
I'm not sure splitting it up on a per-directory level well help that much. If you change a number of files in the same directory, they will have the same prefix and compress well (even without doing any adhoc prefix compression schemes). Changes are quite high that larger commits will scatter around many directories, it's a common theme i.e. for API changes in larger projects. The primary reason for storing tree objects in something like git is the lack of better indexing structures, I would say. In short, I would strongly distinguish between storage format and working format, optimizing the former for compactness and building up the latter when necessary. > > > > (3) Make cluster manifests non-permanent artifacts. > > > > I'm thinking of doing away with cluster artifacts entirely, and > managing sync in some other way. Having something like cluster artifacts can be useful, i.e. consider the typical case of one central main server and many clients pulling from it. If the server builds a ephemeral cluster ever so often and the clients remember the last cluster they got, they can just ask the server "what changed since this point". If the implementation of the communication process is actually asynchronous, adding a few round trips is not that bad as long as the waiting time is minimized. If the first request from the client starts with the last "cluster", the server can answer with the commits added on top. Client can filter out those it already has and request the new ones. While it gets the new commits, it can start requesting the file changes. Non-commit artifacts would essentially work like new leaf commits. A new "cluster" can either reference an existing one as delta or be send from scratch. It would still allow the server to do regular garbage collection. Joerg _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
