Where possible, we used to keep transaction logs in addition to
database dumps. Those can be replayed from the dumped database state
to replay the transactions up to any point by copying and editing the
My best recollection is that they are text and would be suitable for
entry into Git. They are also smaller, and in the case of needing to
recover because of an entry that causes later corruption or problems,
much easier to modify to make corrections or deletions.
What is the purpose of putting the database into Git? If you create
and keep transaction logs (possibly in Git), and have something akin
to a rakefile that creates the original database structure, then the
database itself becomes a derived file, akin to a .pyc file, and can
be recreated at will, so tracking the database, per se, isn't
Just a thought.
On Fri, Aug 10, 2018 at 8:49 AM Greg Wilson <gvwil...@third-bit.com> wrote:
> Hi Tiffany,
> For small SQLite databases, the simplest thing is to dump as SQL text and put
> that under version control. I've done this with DBs up to 100kb or so, and it
> allows diff and merge to work as they usually do. It's...not horrible. For
> larger databases, I've seen groups create a database backup using the DBMS's
> native tool and then use something like Git LFS to manage that backup as a
> binary blob. It works, but you then have to use the DBMS's own tools for
> finding differences and reconciling them.
> On 2018-08-09 10:47 PM, Tiffany A. Timbers via discuss wrote:
> Hi folks,
> I am looking for SQL Database version control tool recommendations? Ones that
> work with Git and are open source are ideal. I have never tread in this
> territory before, so all opinions/options welcome!
> If you cannot be brave – and it is often hard to be brave – be kind.
> The Carpentries / discuss / see discussions + participants + delivery options
The Carpentries: discuss
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription