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  > 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] Release 1.35 checksums?

[John McMurloc]

Faf?

-Original Message-
From: fossil-users-boun...@lists.fossil-scm.org 
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Eduard
Sent: 6. juli 2016 19:40
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Release 1.35 checksums?

On 07/05/2016 02:56 PM, jungle Boogie wrote:
> On 1 July 2016 at 09:39, Warren Young  wrote:
>> If you’re expecting the checksum to protect you against someone hacking the 
>> web site and uploading malware, they can modify the checksums on the web 
>> site at the same time.
> Absolutely.
> 
> As a small request, maybe when Dr. Hipp makes a release, he can also
> include the hash in the email. As Andy indicated, this can be archived
> by search engines and even available on the archive of the mailing
> list.

As a related small request, it would be very much appreciated if more
people (including D. R. Hipp) signed their commits with PGP (in addition
to the build hashes on the site). After all we already have the fossil
'clearsign' setting, it's just a matter of generating a key (gpg
--gen-key) and using it.



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