It gets really difficult to merge changes back again. We have a commercial product that branched once to support a government version. It was a nightmare to later merge changes. The decision has beeen made to never branch again. If bugs need to be fixed, we'll do the work twice, once in production and once in the next rev development. It will end up being easier.


>In the past, I have always worked on small enough teams where we could easily keep development separate from production. Not anymore. We use TFS and have just about finished developing our first "Release", and code-freeze was supposed to have been on Friday (I'm not part of that particular team, so I don't know if they actually did freeze the code on Friday).
>
>But, anyway, I digress <g> ... my question is this. What's bad about branching? I've been tasked with figuring out the best way to separate out our current Release from our development work. As I said, I'm using TFS and it seemed to me that branching was a good idea. IOW, take our current development folders in TFS and branch to a new set of "Release" folders. Any bug fixes will be put in the Release area and merged back to the development area. So our TFS project structure will look something like this:
>
>

>$\Our Applications
>    Folder For App1
>    Folder For App2
>    Folder For App3
>    Folder For App4
>    Folder For Release A (not all Apps were included in this Release)
>        Folder for App2
>        Folder for App4
>

>
>Is this not the recommended approach? If not, what is?
>
>~~Bonnie