On Sep 9, 2009, at 2:04 PM, Shaun Seckman (Firaxis) wrote: > It's always a pleasure to have a new version of one of my favorite > tools. I noticed in the draft that you migrated the project to > Fossil. > I am curious, how was your experience with the migration? Did it go > smoothly or were there many kinks to work out. Also, what was your > primary motivation for migrating in the first place? >
The transfer of version history from CVS to Fossil went relatively smoothly. There were, in fact, some anomalies in the CVS revision history of SQLite back in the 1.x days and so I had to develop work- arounds for those anomalies. But otherwise everything went smoothly. SQLite is the largest (in terms of history) project that we are aware of that is using Fossil, so this was a big step for Fossil. Very early on, the SQLite repository revealed an inefficiency in the implementation of the synchronization wire protocol, which we quickly fixed (http://www.fossil-scm.org/fossil/vinfo/7646ee13e) but other than that, no problems have yet arisen. Fossil is working out very well. We were pleasantly surprised to find that the Fossil repository was an order of magnitude smaller than the original CVS repository. The entire 9.25-year revision history of SQLite can be cloned with only about 13MB of network traffic. There are multiple reasons for changing from CVS to Fossil. (1) The whole point of writing fossil to begin with is so that we could keep tighter configuration control of SQLite. Some customers require this. Others simply want it. As an example of the new capabilities that Fossil provides us, see the new sqlite3_sourceid() C/ C++ interface and the new sqlite_source_id() SQL functions: http://www.sqlite.org/draft/c3ref/libversion.html http://www.sqlite.org/draft/lang_corefunc.html#sqlite_source_id (2) Fossil is a distributed VCS which enables us to work off-line. We are also much less concerned about backups now, since every clone of the repository is a full backup. And we can easily make read/write mirrors of the repository: http://www.sqlite.org/src/timeline (in Dallas, TX) http://www2.sqlite.org/src/timeline (in Atlanta, GA) (3) With Fossil, it is much much easier to go back and create branches to fix bugs in archaic versions of SQLite, in order to support those companies who actually pay us. (example: http://www.sqlite.org/src/vinfo/715cecb8c7) (4) Having the canonical SQLite sources in Fossil makes it easier to create and maintain a private branch of SQLite. See http://www.sqlite.org/privatebranch.html for further discussion. (5) In our experience, Fossil works better than CVS over slow and/or unreliable networks. And, Fossil allows users behind restrictive firewalls to get direct access to the code - something that was never possible with CVS. (6) "fossil diff" is way faster than "cvs diff" (since there is no network traffic with "fossil diff"). D. Richard Hipp d...@hwaci.com _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
