Ok, thanks for clarifying on the comment on rollbacks. Still, I think rollbacks shouldn't be included. From the user's perspecitive there won't be much difference between a rollback and an evolve. In both cases they can write pre and post (or pre_rollback and post_rollback) functions. Granted, they'll have to remember what their models used to look like, but its not really up to us to make backups, right? If a user really wants to rollback a production app, they can get an old version of models.py out of their revision control and evolve with it. If they're prototyping a new app and a change breaks something, chances are they made a small mistake. Don't rollback - fix the mistake and evolve forward.
Its just not clear to me what we're gaining from rollbacks. On the other hand, keeping track of all the shadows will clutter things up a lot in the code and in either the filesystem or database (whereever shadows end up living). Joe --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
