Code

Changes between Version 15 and Version 16 of SchemaEvolution


Ignore:
Timestamp:
06/19/06 17:49:40 (8 years ago)
Author:
Landon Fuller <landonf@…>
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SchemaEvolution

    v15 v16  
    317317An 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. 
    318318 
     319Handling concurrent development -- multiple users and branches 
     320-------------------------------------------------------------- 
     321 
     322Concurrent development requires communication, especially with a shared data store like the database. The above example should never break the production database -- if two developers commit conflicting code, it's up to them to work out the conflict. Preventing the conflicting code from reaching production is an organizational policy issue, not a web framework issue. 
     323 
     324You do raise a good point regarding concurrent development with branches. It's still not possible to get rid of communication -- when it comes time to do a branch merge, discussing database schema will be mandatory. However, the tool should allow for branch merges; why not store a branch name AND a version number for each schema revision? When planning for a branch merge, one can implement a "from branch 1 version 6 to branch 2 version 3" migration. Obviously, migration points will need to be well defined, but supporting branches at least allows for the possibility. 
    319325}}}