Context Navigation

Changes between Version 14 and Version 15 of SchemaEvolution

-              v14
+              v15
 .. _TheProcessOfDatabaseRefactoring: http://www.agiledata.org/essays/databaseRefactoring.html
 .. _RefactoringDatabases: http://www.bookpool.com/sm/0321293533
+Why something different
+-----------------------
+I agree with "Something Completely Different" above. I worked on a Java-based product that used a similar approach to numbered schema versioning (although we worked with serialized objects in the backend instead of a relational DB). We had trouble merging changes with conflicting version numbers. This was not initially a huge problem for us, because we had very little overlap within and between our projects. However, the times that it happened it was a big deal, and as soon as we started real parallel development, it became a critical issue. I think for Django teams this is a killer, because deployments are so quite common and testing tends to be a part of the developers roles.
+An example is svnA user creates schema version 5, while concurrently svnB makes version 5. Everything is fine until merge, then either user has an unusable database. This is bad enough, but consider branches! It gets ugly, and can easily break the production database at unexpected times.
 }}}