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 do this in plain text but you could if the data is small, and that could go in version control. I suppose creating db backups is more common in service based dbs (mysql, postgres, etc). As for the history, versioning etc, of the db, just look at normal backup workflows and get used to that the db data is separate from the Django code. Enjoy, Alex On 02/25/2016 11:23 AM, cortez wrote: > 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 > copies. > > On Thursday, 25 February 2016 18:25:47 UTC, Daniel Roseman wrote: >> >> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/56CF56D6.2050102%40wildintellect.com. For more options, visit https://groups.google.com/d/optout.
