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
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
>
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
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
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
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
6 matches
Mail list logo