R
Rod at Work
Guest
A couple years ago I asked here in this forum a question, Have some more questions about creating a template project. That question was answered.
However, I realize now that I wasn't asking the right question, so I'm back to improve the question I really would like answered. Let me give a little background. I work on a small team in a government agency. We're working to replace some very old applications, written either using MS Access or entirely contained within Excel spreadsheets, with something more modern and certainly more easily maintained. We wrote a main app, which we call Core. It's checked into TFS. It doesn't do anything "real", as in it doesn't work against data of any importance. It's just there to work out functionality. Then, what we've been doing, when we need to create a new app based upon Core to address replacing one of these legacy Access app or Excel spreadsheet, is someone gets into Visual Studio or TFS, to branch Core into a separate branch, for the new project. This new branch is never meant to be merged back into Core, as you would normally do when branching a project in TFS (or any other source control system). And to make matters worse, in complete violation of the DRY principle, if some change to the basic functionality is done within a child branch, it must manually be duplicated in Core and all other projects branched from Core. And of course if anyone makes any change in Core, it must be manually duplicated to all child branches.
I was bothered by this two years ago and I'm even more bothered by it now, because we're making more branches to address really old apps. This practice doesn't make sense, which is why I asked the question I linked to previously. I thought that somehow a template project would handle this problem. I now realize that question was the wrong question to address our needs. So, I'm asking here, what is a better approach so that if we need to make a change to code that is in Core or any child branch from Core that affects code within Core, that code change can better be migrated to all projects branched from Core as well as put into Core?
Rod
Continue reading...
However, I realize now that I wasn't asking the right question, so I'm back to improve the question I really would like answered. Let me give a little background. I work on a small team in a government agency. We're working to replace some very old applications, written either using MS Access or entirely contained within Excel spreadsheets, with something more modern and certainly more easily maintained. We wrote a main app, which we call Core. It's checked into TFS. It doesn't do anything "real", as in it doesn't work against data of any importance. It's just there to work out functionality. Then, what we've been doing, when we need to create a new app based upon Core to address replacing one of these legacy Access app or Excel spreadsheet, is someone gets into Visual Studio or TFS, to branch Core into a separate branch, for the new project. This new branch is never meant to be merged back into Core, as you would normally do when branching a project in TFS (or any other source control system). And to make matters worse, in complete violation of the DRY principle, if some change to the basic functionality is done within a child branch, it must manually be duplicated in Core and all other projects branched from Core. And of course if anyone makes any change in Core, it must be manually duplicated to all child branches.
I was bothered by this two years ago and I'm even more bothered by it now, because we're making more branches to address really old apps. This practice doesn't make sense, which is why I asked the question I linked to previously. I thought that somehow a template project would handle this problem. I now realize that question was the wrong question to address our needs. So, I'm asking here, what is a better approach so that if we need to make a change to code that is in Core or any child branch from Core that affects code within Core, that code change can better be migrated to all projects branched from Core as well as put into Core?
Rod
Continue reading...