On Sat, Jul 8, 2017 at 10:43 AM, Chris George <[email protected]
<mailto:[email protected]>> wrote:
Here is one approach to using sqlite with git.
https://ongardie.net/blog/sqlite-in-git/
<https://ongardie.net/blog/sqlite-in-git/>
Thanks for this. And here is a stack overflow response
<https://stackoverflow.com/questions/846659/>.
All this research is a ton of fun.
Edward
Thanks Chris and Edward.
Let me say that I also made a minimal research of the matter before my
posts, with the following several search terms:
* sqlite binary git
* sqlite git diff
* sqlite git howto store
and came across the same links and some other, including the one at
stack overflow
<https://stackoverflow.com/questions/550566/sqlite-table-with-git-merging/551409#551409>
that I referenced in my previous post.
The fact is that, altough the answer I selected in that SO thread has
only 1 upvote and was not marked as "best answer" by the OP, *was at the
bottom of the list of answers* (1), I saw it as "the most accurate"
considering my own experience in the matter (database import/export
tools of various DBMSs, including Sqlite).
But as I try to be "scientific" in programming work and prove if my
hypothesis are true or not with facts if I can, and not just
"sensations", I've made the following test to see if the "sqlite3 .dump"
command could really be used for that purpose as many posts propose:
* I have created this repository at GitHub for the tests:
https://github.com/xgid/leo.db-vcs-tests
* I have saved my workbook.leo file as *workbook.leo.db* using
the*sqlite-leo* branch created by Vitalije
* Closed the file and generated the dump file
*workbook.leo.db_dump.sql* using the .dump command of the sqlite3 tool
* Committed and pushed both files to GitHub
* Opened the workbook.leo.db again and changed just the order of two
nodes, made a minor change in the body of another and changed the
position and size of the window
* Closed the file and generated the dump file
*workbook.leo.db_dump.sql *again using the .dump command of the
sqlite3 tool
* Committed and pushed the new files to GitHub (5648c4e
<https://github.com/xgid/leo.db-vcs-tests/commit/5648c4ea02c9e1f47efe86ec990fc9aff6554c11>)
To my surprise, the resulting diff is even worst than I thought it would
be:
https://github.com/xgid/leo.db-vcs-tests/commit/5648c4ea02c9e1f47efe86ec990fc9aff6554c11?diff=unified
(you will have to click the "Load diff" to see it the diff of the
*workbook.leo.db_dump.sql *file because GitHub prevents rendering long
diffs by default)
*Conclusion for the part that interests us right now: *
The sqlite dump command is not usable as a means of generating nice
diffs of the changes in .leo.db files.
It is so because the sqlite dump command (as I suspected) does not
generate a "normalized" (as to say) output format, in the sense that it
does not output the various tables in the db file _always __in the same
strict order_ (and it will probably be the same with the order of the
rows in each table, althoug I have not verified it yet).
The good news are that Offray and Vitalije *have already provided the
solution to this problem*: use the .leo XML file format as export format
and store that in git, instead of the (raw) sqlite dump. Well, at least
the old .leo XML format will be of some use! ;-) (this is a joke!)
I wish us all the best grit!
Xavier
(1) It's been a good surprise to see that that answer today is not at
the bottom of the list of answers any more, because there's a more
recent answer <https://stackoverflow.com/a/44992436/5104752> (posted
just 5 hours ago!) adding yet another interesting option to the
question. Maybe we'll have to give it a try also...?
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
