On 9/2/14, 8:02 PM, Ron W wrote: [...] > I think that the only way this will happen would be to fork Fossil into a > new project. This would be because of the overall underlying goals of the > Fossil project vs a "Fossil-saurus" project.
It may be plausible to simply implement a RDBMS wrapper library which presents a SQLite-like API. That would neatly encapsulate and translate all the SQLite-isms used by Fossil, which means you wouldn't have to change Fossil at all. I have no idea whether this is feasible or not. I don't really know how different SQLite's SQL dialect is from other databases --- since discovering SQLite I haven't really felt a need to get into MySQL or Postgres --- and there may also be killer non-API assumptions: e.g., with SQLite, local processing is cheap. With a remote DBMS, local processing is expensive, because you have to push all the data over the wire. So if Fossil's expecting to be able to cheaply enumerate big chunks of the version graph, that's unlikely to adapt well to a remote database. [...] > As for Fossil itself, it probably scales better than most people think. > Part of the problem is perception. I believe NetBSD has one of the bigger Fossil repositories, and they've complained that some Fossil operations are slow (commits and updates --- http://2011.eurobsdcon.org/papers/sonnenberger/fossilizing.pdf claims 8-10 seconds for an operation which git and hg do in 1. I have a vague memory of a discussion here coming to the conclusion that this is because of large chains of deltas having to be resolved? (I myself have a 250MB Fossil repository with a number of large files in it (multi-megabyte jpegs) and have noticed that operations are noticeably slower there than on small repositories.) [...] > I know many people who are more comfortable with "large scale" systems like > Perforce, because they are used to working in large organizations. Perforce handles very, very large repositories very well. (Repositories too large for git.) e.g.: http://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/34459.pdf Brief summary: it says that Google's VCS, as of 2011, had 200GB of *metadata* (amount of actual data is unspecified) and did about 25qps. (Perforce is *weird*. You thought git was weird? Go use Perforce.) -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ "Feminism encourages women to leave their husbands, kill their │ children, practice withcraft, destroy capitalism and become lesbians." │ --- Rev. Pat Robertson
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
