Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[Stephan Beal]

On Wed, Jul 27, 2016 at 8:55 PM, Adam Jensen  wrote:

> Does anyone know of a [libfossil](http://fossil.wanderinghorse.net)
> mailing list? Or is it cool to talk about such things here?
>

No and yes.

i'm the originator of libfossil, but a severe inflamed elbow nerve, caused
by too much typing, limits me, more often than not, to single-handed
typing, which has meant essentially no programming for me since December,
2014 :/. So... the brakes are on libfossil's development until either my
elbow recovers or someone steps up to get it going again. (Volunteers are
of course welcomed :D.)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[John McMurloc]

?

-Original Message-
From: fossil-users-boun...@lists.fossil-scm.org
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Adam Jensen
Sent: 27. juli 2016 20:56
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] fossil-scm as an SQLite db with schema/data
revision control

On 07/27/2016 10:37 AM, Ron W wrote:
> On Sun, Jul 24, 2016 at 10:58 PM, Adam Jensen <han...@riseup.net
> <mailto:han...@riseup.net>> wrote:
> 
> 
> [The Session Extension](http://www.sqlite.org/sessionintro.html)
pointed
> out by Eduardo seems to have a lot of potential.
> 
> "The session extension provides a mechanism for recording changes to
> some or all of the rowid tables in an SQLite database, and packaging
> those changes into a "changeset" or "patchset" file that can later be
> used to apply the same set of changes to another database with the
same
> schema and compatible starting data. A "changeset" may also be
inverted
> and used to "undo" a session."
> 
---

> Eduardo's description of the SQLite extension only talks about table
> data. This would still leave a need for managing schema updates.
> 

Interesting, I didn't interpret it that way.

> If this SQLite extension also handles schema updates, then probably no
> reason to use tickets.
> 

I suspect it does but I haven't tested that suspicion yet. I've compiled
SQLite with support for the Session Extension but section 2.0 of the
documentation - "Using The Session Extension" - is empty.

> In either case, the actual changesets should be suitable to manage as
> files in Fossil.
>  

I suppose when Fossil manages a file, from one version (check-in) to the
next it is a diff of some kind that is actually recorded and generating
the diff is an internal mechanism that is part of the check-in process.

Imagining a custom system for distributed version control of an SQLite
database, composed of components harvested from Fossil (but not a
standard-off-the-shelf Fossil system), the file being managed might be
something like a .dump of the database and the current Fossil diff
mechanism could (abstract concept) be replaced with the Session
Extension method of generating diffs (changesets).

Does anyone know of a [libfossil](http://fossil.wanderinghorse.net)
mailing list? Or is it cool to talk about such things here?

___
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

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[Adam Jensen]

On 07/27/2016 10:37 AM, Ron W wrote:
> On Sun, Jul 24, 2016 at 10:58 PM, Adam Jensen  > wrote:
> 
> 
> [The Session Extension](http://www.sqlite.org/sessionintro.html) pointed
> out by Eduardo seems to have a lot of potential.
> 
> "The session extension provides a mechanism for recording changes to
> some or all of the rowid tables in an SQLite database, and packaging
> those changes into a "changeset" or "patchset" file that can later be
> used to apply the same set of changes to another database with the same
> schema and compatible starting data. A "changeset" may also be inverted
> and used to "undo" a session."
> 
---

> Eduardo's description of the SQLite extension only talks about table
> data. This would still leave a need for managing schema updates.
> 

Interesting, I didn't interpret it that way.

> If this SQLite extension also handles schema updates, then probably no
> reason to use tickets.
> 

I suspect it does but I haven't tested that suspicion yet. I've compiled
SQLite with support for the Session Extension but section 2.0 of the
documentation - "Using The Session Extension" - is empty.

> In either case, the actual changesets should be suitable to manage as
> files in Fossil.
>  

I suppose when Fossil manages a file, from one version (check-in) to the
next it is a diff of some kind that is actually recorded and generating
the diff is an internal mechanism that is part of the check-in process.

Imagining a custom system for distributed version control of an SQLite
database, composed of components harvested from Fossil (but not a
standard-off-the-shelf Fossil system), the file being managed might be
something like a .dump of the database and the current Fossil diff
mechanism could (abstract concept) be replaced with the Session
Extension method of generating diffs (changesets).

Does anyone know of a [libfossil](http://fossil.wanderinghorse.net)
mailing list? Or is it cool to talk about such things here?

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[Ron W]

On Sun, Jul 24, 2016 at 10:58 PM, Adam Jensen  wrote:

>
> [The Session Extension](http://www.sqlite.org/sessionintro.html) pointed
> out by Eduardo seems to have a lot of potential.
>
> "The session extension provides a mechanism for recording changes to
> some or all of the rowid tables in an SQLite database, and packaging
> those changes into a "changeset" or "patchset" file that can later be
> used to apply the same set of changes to another database with the same
> schema and compatible starting data. A "changeset" may also be inverted
> and used to "undo" a session."
>
> Wow, whoever designed that extension had Vision.
>
> Given this capability, would you still use Fossil tickets to record,
> manage, and communicate the changesets or do you suppose the changesets
> (or some variation) might somehow be stored in the blob table?


I was only suggesting tickets for the schema updates.

Eduardo's description of the SQLite extension only talks about table data.
This would still leave a need for managing schema updates.

If this SQLite extension also handles schema updates, then probably no
reason to use tickets.

In either case, the actual changesets should be suitable to manage as files
in Fossil.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[Adam Jensen]

On 07/25/2016 04:38 AM, Carlo Miron wrote:
> See also [rqlite] (https://github.com/rqlite/rqlite).
> 

Hey, sweet! That might be slick for situations where three to nine
SQLite databases need to be continuously synchronized through automated
consensus. That scenario is quite a bit different from DVCS on a
database, but it's nifty nonetheless. Thanks for the reference, I'm
tinkering with rqlite now :)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[Carlo Miron]

See also [rqlite] (https://github.com/rqlite/rqlite).

㎝

-- 
|:**THE BEER-WARE LICENSE** *(Revision 42)*:
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[Adam Jensen]

On 07/23/2016 07:05 PM, Ron W wrote:
> Hello,
> 
> What you are thinking is not impossible.
> 

Thanks for the confirmation, I've been speculating about novel system
architectures and unusual use-cases without sufficient fundamental
knowledge and experience - that makes for dangerous propositions and a
very delicate position. Thanks again, for the sanity check.

> 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.
> 

We're probably on the same page here. I've recently opened a fossil
repository file with the sqlite3 application and explored the schema
(superficially).

> 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.
> 

I think I get the gist of what you are saying. At some point it would
probably be worthwhile [for me] to explore the communication protocol.

> 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).
> 

That might be an interesting approach to putting together a prototype
demonstration-of-concept system, just using standard Fossil and SQLite
and some scripting.

[The Session Extension](http://www.sqlite.org/sessionintro.html) pointed
out by Eduardo seems to have a lot of potential.

"The session extension provides a mechanism for recording changes to
some or all of the rowid tables in an SQLite database, and packaging
those changes into a "changeset" or "patchset" file that can later be
used to apply the same set of changes to another database with the same
schema and compatible starting data. A "changeset" may also be inverted
and used to "undo" a session."

Wow, whoever designed that extension had Vision.

Given this capability, would you still use Fossil tickets to record,
manage, and communicate the changesets or do you suppose the changesets
(or some variation) might somehow be stored in the blob table?

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[Eduardo Morras]

On Thu, 14 Jul 2016 14:31:46 -0400
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).

You can use the Sqlite session extension to produce patch files between
db file versions. It has some restrictions on schema and documentation
is scarce, but if I had the same goal as you, I'll try that way.

To use it you need Sqlite version >= 3.13.0

www.sqlite.org/sessionintro.html
 
> 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 .


---   ---
Eduardo Morras 
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[Ron W]

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  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 .
> >
> > ___
> > fossil-users mailing list
> > fossil-users@lists.fossil-scm.org
> > 

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[Paul Hammant]

Adam,




> 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).
>



If you want to use a generic SCM for versioning of *app data*, you should
really think of a document store, where a schema-less document (JSON) is in
a file ins source-control, and you're bumping HEAD revision in your app.
That could be on your fork, or a shared repo. If your fork, then merge
plays a part later on. For less merge clashing because of whitespace diffs,
YAML or TOML could be better formats. There's plenty of examples online for
this sort of thing. Hit me up off the list if you're wanting more. Here's
me writing about "very small data" -
http://paulhammant.com/2012/11/20/very-small-data/ - which might have a
bearing on your thinking.

- Paul
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[Jonathan Otsuka]

For schema versioning I would look into alembic. 
https://bitbucket.org/zzzeek/alembic

It allows you to upgrade and downgrade between revisions.  I have only used 
this in Python projects, but there isprobably  something out there for other 
languages. 

Jonathan Otsuka

> On Jul 23, 2016, at 2:57 PM, Adam Jensen  wrote:
> 
>> On 07/23/2016 03:37 PM, Richard Hipp wrote:
>>> On 7/23/16, Adam Jensen  wrote:
>>> I'm a little puzzled by the lack of response
>> 
>> Lots of people on vacation.  Not much activity on *any* project during
>> the summer months
>> 
> 
> I'm beginning to suspect that I might have proposed something based in
> such compounded ignorance that there's no simple way for anyone to
> explain the problems of it to me... which is totally cool, I'm somewhat
> out of my areas of competence here.
> 
> ___
> 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

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[Adam Jensen]

On 07/23/2016 03:37 PM, Richard Hipp wrote:
> On 7/23/16, Adam Jensen  wrote:
>> I'm a little puzzled by the lack of response
> 
> Lots of people on vacation.  Not much activity on *any* project during
> the summer months
> 

I'm beginning to suspect that I might have proposed something based in
such compounded ignorance that there's no simple way for anyone to
explain the problems of it to me... which is totally cool, I'm somewhat
out of my areas of competence here.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[Richard Hipp]

On 7/23/16, Adam Jensen  wrote:
> I'm a little puzzled by the lack of response

Lots of people on vacation.  Not much activity on *any* project during
the summer months
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[Adam Jensen]

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 .
> 
> ___
> 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

Re: [fossil-users] fossil-scm as an SQLite db with schema/data revision control

[Adam Jensen]

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