This project is read-only.

How to handle version collisions?

Sep 23, 2011 at 8:14 PM

How do you handle version collisions?  In an environment with more than a single developer, it's possible for two devs to be working on migrations at the same time.  Therefore, it's possible that they both version their migration with the same version number.  What happens then?

Also, what's the best way to keep track of the most recent version number?  It would be a real pain to have to open every migration class just to find the latest version number.

Sep 24, 2011 at 10:58 AM

I handle it by keeping all the migration attributes in a common file rather than in the same file as the migration class. This doesn't completely solve it, but it at least makes it easy to find the latest number and quickly check during merging if a number has been reused.

Sep 26, 2011 at 3:47 PM

Thanks for that tip.  That will probably work just fine for us.  One other question for you:  Do you have any tips on organizing the migration classes?  I'm just not keen on dropping them all in the root of a migration project.  At some point, it will begin to get rather noisy with all the classes in the same place.  I was thinking of possibly dividing them into two folders: schema and data.  Do you have any tips on this?

Sep 27, 2011 at 12:36 AM

I don't have any great tips for organisation. I think the schema/data split you mention sounds good (I don't tend to do much data in my migrations). I sometimes keep related migrations in a common file - e.g. I might have a file for each table with all the migrations related to that table in the same file so you can easily scan down the file and see the changes the table has gone through.