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 .
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
