That definitely sounds like something that would have made my customizations a bit less. From my understanding there are still a few key differences in the approach I took (although no reason why the trunk build couldn't be extended to accomodate it). 1) A couple of the 'static' configuration parameters (like environment 'DEV', 'TST', 'UAT', 'PRD') are actually sourced from the ProjectGrid.vm template and then stored in the database for that specific run. This was mainly done because the out of the box communication didn't support any sort of parameter passing, which sounds like is available now in 1.5
2) Whenever a 'tag' is created, this builds a new 'deployable version'. 'Deployable Versions' are another propertyset that I allow choosing from. So since my store is the database, it is easy for me to store these and then retrieve them from there. In a ccnet.config storage scenario I would be trying to update values as part of a build. Probably could be accomplished with the xml includes, I'd have to play around with it. The fact that parameter passing also works from CCTray is great and something that because the back-end process didn't support parameter passing, I didn't bother to try to extend the CCTray as well. I don't actually store the parameters in the trunk, but the version # parameters are specific to each build and updated anytime that a 'tag' build is run. My build files for deployment expect a source binary deploy tag and then the environment. Then an entire parameter value set is what is stored in the trunk in source (connection strings, deployment folder, etc)
