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.

>The same problems exist with text files (like prgs, etc). We've made the decision to not branch as it caused more problems than it solved...and these are all C++ text files. We make the changes in multiple versions. At some point you say, "we won't support anything older than version x."
>
>
>>Ok, fair enough. How to handle making sure that we can work on new development (projects) and also bug fixes to production when they both share the same code? Right now, I have some processes in place where I keep things local in a project (backed-up and archived of course) and only check them all back in when they are close to release. The other guy does it similar to me, though not near as retentive in making sure that the files are in sync. Things like binary files, especially the project always have to be manually figured out. Also, it's just hard because the codeset you started with back a few months ago has changed due to production fixes and now you have to merge everything all over again Seems like there has to be a better way of doing it.