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

Reply via email to