Thanks Alex, that's great information, I shall dig in.
C
On Thursday, 25 February 2016 19:33:06 UTC, Alex wrote:
>
> Normally for a site you don't keep your db in version control because
> the table definitions come from Django. Now if you have data to
> prepopulate (each time you fresh clone)
Normally for a site you don't keep your db in version control because
the table definitions come from Django. Now if you have data to
prepopulate (each time you fresh clone) or need to do a backup then use
standard db backup mechanisms.
Like dumping your db to an sql backup. It's not efficient to
Well I don't, but I'm not sure what the alternatives are. I mean what I'm
interested in are *alternatives* to keeping it under version control, so I
have backups, history, versioning. Preferably something I can easily
integrate with my Django workflow, without having to manually keep external
c
Why do you want your db in version control at all? There is not normally a good
reason to do that.
--
DR.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to djang
I put my sqlite files into .gitignore.
Rafael E. Ferrero
2016-02-25 12:55 GMT-03:00 cortez :
> Hi,
>
> I'm using the out-of-the-box Sqlite database integration with my Django
> project, and I'm wondering how to manage it with respect to Git. Currently
> I have it checked in, but I suspect this
Hi,
I'm using the out-of-the-box Sqlite database integration with my Django
project, and I'm wondering how to manage it with respect to Git. Currently
I have it checked in, but I suspect this isn't what I want to be doing.
Also I have noticed that every time I log in to the admin interface and
6 matches
Mail list logo