Me and the other coder have been editing database changes on a staging version and a new developer made his own changes locally and just wrote .sql files that he expected us to run (without even telling us), and when I brought it up he insisted that we do it that way, however he was not consistent about it and we had already diverged. It took us a while to sync it all up, but he's expected us to just look at his commits and run his files (even though he's modified them, diverging his own db) and us do it the same way in this chaotic fashion, so I wrote a file that lets us create change files and run them automatically in a parent file. However, he's said it's too complicated for him (even though I previously explained it to him and he got it and liked it and said he would use it), and now he's said he'll just use CakePHP migrations for his changes, diverging from us further, not including us in that system because he says it isn't finished yet, so now when we start using it he'll either have to throw away his migration files (so we can start at a fresh version of the database) or we'll have to merge out changes in, breaking his migration files or causing us undue work writing our own to sync with it... this sounds like total chaos.
I want to say "Let's either use your system now or when you get it working, let's start at this version of the database and then start creating our migration files". If he insists on keeping his own migration files, I'm not sure what to say at that point.
How is this supposed to be done and what do you think of this?
03-20-2013, 06:11 PM
I think you should jump onboard and see how deep the rabbit hole goes :D
but that may just be my courageous youth talking
also, if you're using some type of version control.... he should have branched and then you can later merge
IMHO: anyone that creates the branch SHOULD be responsible for merging it back in, at least in this type of situation.
without the branch, it's never going to be clear exactly what happened.
I suggest you work with him to settle on a database schema to get a working version you can both agree upon,
ONLY THEN do you start making more changes to the schema, and those should always be on a branch with the respective code that requires the changes.