Yeah, I didn't mean merge in the literal sense, more of just making manual changes when differences are known/discovered. How do you keep developers from walking over each other's stuff though? That's what I'm really after. More of a process. I understand about making changes across versions, but in the examples I asked about, there is all kinds of room for error and things getting missed. Multiple developers, multiple projects, production code, etc. Just seems like there should be a way to handle it all without having to call each other up and ask "So, hey, do you recall what files you changed for your project, because I'm getting errors, blah, blah, blah..."

>No merge. Period. We make the changes in multiple versions, if needed. Some bugs we don't fix until a new release, if there is an acceptable work around.
>
>
>>So you make the identical changes in all versions that will require it. What do you do if you are working on a project to be release in 6 months? Just take a snapshot of the production version. keep it separate and then merge everything at the end? That's the part to me that gets muddled because during that 6 months changes are being made to production. You make all those changes ongoingly to both production and the new project? What if there are more than one project going on, plus production? It just seems like a huge chore to keep it all straight and not introduce bad code into production.