The main difference would be that you now have to think "across" the version tree as well, rather than only "along" it. Your QA people still check out a specific name (it'll be a branch, not a tag), and test it, so their job doesn't change. The difference will be with the cross-dependancies.
To your example, the repository has fileA and fileC. Developer A creates a branch, modifies both files, as well as adds a new file: fileB. Once he's ready, he sends off his branch to QA for testing. In the meantime, Developer B creates a branch, modifies fileC and adds fileD, and then sends his branch of to QA. Note that both changes sets are, at this point, totally independant of each other, and of the main development branch (the trunk). DevB's changes come back as golden, and DevA's changes come back as broken. DevB then merges his changes into the trunk (for permanent use), and DevA is back where he started with his files that need to be prepped for QA. The difference is that his files are also outdated because of DevB's commit to the trunk. So he needs ot merge the mods from the trunk into his sources before he fixes whatever QA was complaining about. Assuming things go well, when QA gives the OK, he'll merge his changes back into the trunk as well, and then both developer's changes will be "active". There is another way to handle the second block: DevA continues to work on his code as-is, without including DevB's changes that were merged into the trunk. Then, when QA's satisfied, and he merges into the trunk, he can deal with DevB's changes at that point. This alleviates DevA from having to deal with DevB's work during his specific task, but adds the requirement for some "integration" QA. That is, QA after the merge, as well as for the specific enhancement in isolation. Regarding your different workspaces, every developer and QA person should have their own personal working directory checked out. The QA people will be switching their working directories between branches all the time, while the developers will be switching far less (primarily back and forth between the trunk and their active branch). cheers, barneyb On 3/28/06, Rich Kroll <[EMAIL PROTECTED]> wrote: > Michael, > Thanks for your response. Can I ask how you implement promoting branches to > a QA environment? As it stands for us now, we have one set of code in a > directory on another server that we use for testing, and have built a CF > engine to roll back files if they fail QA. We currently have quite a few > people working in QA that are testing different tasks yet all work on the > one unified code set. If we promote these branches to testing, would it > still be one code set, or would we need different virtual directories to > test the different branches? > > We're currently using DW8, but are considering moving everyone over to > eclipse for it's integration and amazing price point ;) > > Again, thanks for your help in getting me to understand the theory of how > this type of setup would work. > > Rich -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:236369 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
