Hello, What you are thinking is not impossible.
You do need to be aware that Fossil only uses SQLite as an index engine. Fossil does not synchronize the actual databases, only the "artifacts" (stored as "blobs" in the database). Aside from the blob table, the tables in the database are derived from the information in the artifacts. When information in a Fossil repository is added or updated, Fossil creates new artifacts to contain the new or update information, stores those in the blob table, then updates the various other tables. When Fossil pushes to or pulls from another repository, only blobs are transferred. The receiving Fossil adds those to it's blob table, then updates the other tables as needed. Fossil could be used to synchronize 2 or more SQLite databases. Schema updates could be handled as tickets, the body of each ticket containing the SQL commands required to make the schema changes. For new clones of the database, a serialized version of the schema could be used, rather than "replaying" the schema tickets. Synchronizing tables would require serializing their content into artifacts, which Could then be pushed/pulled normally by Fossil. The serialization of the schema and the table contents would have to be done by an external application. Maybe libfossil could help with that. Otherwise, each new artifact could be created in to a file, then the files committed into Fossil using system() calls to invoke Fossil's command interface. Alternately, the artifacts could be added as wiki pages via Fossil's HTTP interface (which would avoid launching the Fossil application multiple times, though the push/pull would still have to be done via the command interface). On Sat, Jul 23, 2016 at 3:33 PM, Adam Jensen <han...@riseup.net> wrote: > I'm a little puzzled by the lack of response - good, bad, ugly, be gone > with you - anything will do. Is this kind of speculation taboo in this > community or does it just take time to ponder the implications? Would > the SQLite developer list be more appropriate/receptive? I'm very > unfamiliar with these communities and I am concerned that I might have > stumbled into some kind of faux pas here. > > > On 07/14/2016 02:31 PM, Adam Jensen wrote: > > I sent a message last night before joining the mailing list (today) and > > I'm not certain if it (last night's post) was distributed to the list or > > not. It's not displayed in the list archive yet. Just in case, here it > is: > > > > On 07/13/2016 06:18 PM, Adam Jensen wrote: > >> This might be a bit convoluted but is it possible to use fossil-scm as > >> an SQLite db with the schema/data under revision control? If this > >> functionality doesn't already exist in fossil, would it be difficult, > >> awkward, or crazy to try to implement it? > >> > >> It seems like such an obvious thing to do that I guess it either already > >> exists or it's so technically twisted that it's virtually impossible. > >> > >> If this functionality doesn't exist, how would you do it? > > > > After thinking a little more about this, it seems like maybe this isn't > > something that should be incorporated into Fossil [or SQLite] but rather > > this could be a third system that is based on the other two. > > > > To add a little more verbiage and description to the basic idea, what I > > am imagining is (I'm going to assume that in this new system a single db > > file can support multiple databases) an SQLite database with version > > control on the schema and data. This might be accomplished in a fashion > > similar to the original SCCS - every SQL command that causes changes to > > the [working copy] database is saved in the version history (a > > fossil-like database in this common db file). With this, any version of > > the database could be recreated by replaying the history. This process > > could be sped up by saving or creating snapshots of the database at > > various moments in its history (all in the common db file (and, perhaps, > > read-only)) and then a specific version can be created by replaying the > > relevant set of SQL changes made after the snapshot. (This description > > is just to get the idea across; there are probably more clever ways to > > implement it). > > > > Another aspect of this third system is the typical fossil-like data > > sharing. So basically, this could be a distributed, multi-user database. > > Each user would have a local copy (fast access) with their own branches > > (write control) but there could be data sharing through merges. (This > > probably sounds obvious to fossil users but think about it from the > > perspective of sharing database content rather than sharing a pile of > > files (source code). > > > > For fun, and somewhat whimsically, a name for this Fossil/SQLite hybrid > > might be DVCSQLite <smirk>. > > > > _______________________________________________ > > fossil-users mailing list > > fossil-users@lists.fossil-scm.org > > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
