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
