On Tue, Sep 2, 2014 at 10:18 AM, <sky5w...@gmail.com> wrote: > Can Fossil offer 2 solutions? SQLite based and PostgreSQL(insert big RDB > here)? >
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. As I understand it, Fossil is intentionally designed around the feature set provided by SQLite. Therefore, to support DB back-ends other than SQLite would not just require rewriting SQL queries, but significant re-working of Fossil's C implementation. Certainly, a huge scale DVCS like Fossil would be a good thing. A key question for a potential project team will be: Once you separate out the DB back-end, where do you draw the line? As for Fossil itself, it probably scales better than most people think. Part of the problem is perception. Part of the problem is lack of certain features that some people consider desirable or essential. I know many people who are more comfortable with "large scale" systems like Perforce, because they are used to working in large organizations. And I know that some of those do/did work on large software teams. The rest are like me: The overall "software team" is large, but for any given project, the number of software members is usually 2, sometimes 1 or 3, rarely more than that. The "high ceremony" system we are supposed to be using is not helpful to us.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
