We have one TFS Project with about 30 applications under source control. Unfortunately, under the previous contract they consolidated the Database scripts (Stored Procedures, Triggers, .bat scripts, etc.) for all these applications so that one file (a .sql, for instance) will be used for multiple applications. I don't know how it all works (they realize it was probably a mistake, but don't have time to unwind everything), but the problem is that this Project gets frequent build requests and customer releases (for evalutions and such, not full releases) - usually weekly and sometimes daily. The problem is that these build requests and releases will affect several of these Projects at a time. Therefore, everytime this is done (weekly/daily), the DB files must be updated individually for each application included in the request, usually at least several and sometimes all. As a result, they need to keep track of up to 30 different versions of most of the SQL files/projects on a weekly or daily basis. Right now, as I understand, they just make different local copies of all of this and they know which ones to send out to whom.Additionally, the order of operations to fulfill these requests is for the Developers of the db files (2 of them) to pass along their files to a CM person (1) and then the CM passes it along to the Testers, then to the Builders and finally to a release. The basic structure we have set up is a "Continuous Build" (I think) - There is Project-level directory called "Working_Baseline" in which all 34 applications have their development branches. Within this "Working_Baseline" branch, there are 3 parent branches, one called "Integration" (used by CM), one called "Development" and "Branches" - these last two used by the developers. They are supposed to make branches from the "Development" Branch (this counts as their starting point) into the Branches folder, do their development there (as many branches as they need), then Merge back into the Development branch. They then tell the CM person what items (by Labels, Changesets, Date, ?) are required for the request, then the CM person Merges from the Development branch into the Integration Branch. Then, the CM merges from this Integration branch into a corresponding branch in another Project-level directory called "Production_Baseline" - this is the one from which files are drawn to send to the Builders/Testers. (Also, they are not using TFS for Building - they take complete file packages and move them to another server using some other tools for the actualy builds, tests, etc.).Anyhow, this process seems to work for all the non-DB projects. They generally have a few working branches at a time, so it's manageable. We are doing our first real Merge from the developers to the CM next week.However, the problem is that while the non-DB developers can isolate their work by branches and still have a managable number of branches, it looks like if the DB project uses this method, they'll need up to 30 branches each time a request comes out because they need to have a separate version of their project for each of the 30 others. So we played around one day with some alternatives - I suggested they just use 1 Branch for all their work and then keep track of things by Changeset and/or Labels. There were several problems with this: 1st - they need to keep track of which Changesets/Labels contain which updates for each application, and this didn't really relieve them of the work, 2nd - whenever they attempted to get the latest into their Workspace for a particular file there were several steps required for "resolving conflicts" even though "overwrite" was selected (the option of having 30 separate workspaces per request and per application has it's own problems); it was also hard to figure out which one was correct (workspace version, server version, by date, etc., requiring a lot of comparisons), 3rd - the same thing happened during Merging, each time we tried a Merge by Changeset or Label, we had to resolve conflicts (each requiring several steps), 4th - then, once we had the merge completed, we noticed that the merge produced it's own new Changeset number and the Label applied to the working copy did not carry over into the Branch it was merged into; this means that as everyone passes along files up the chain (there are about 4 or 5 merges altogether to get to the release stage) a new set of changesets/labels has to be kept tracked of. What we were really hoping for was a way to identify a set of work with one identifier that could easly be carried on to any other Branch without any changes. As a result of all the work this all appears to take, the DB group has put in a request to be waived from the requirment to use TFS (they have licences for and are familiar with another source control project, Dimensions).Anyway, as I'm new to this too, I didn't know how to offer the best solution for this situation. Given the number of file versions they need to keep track of on such a frequent basis, what is the best option for this DB project? Also, is there a better way to set up our Branching for the normal applications?
The new partial projects in the new Visual Studio Team System 2008 Database Edition GDR - RTM might solve you problem.
- Proposed as answer by Ewald Hofman - TFS Product TeamMicrosoft employee Friday, December 05, 2008 9:05 PM
I see that this might help over the long run, but with their work load, the DB team (there's only 2 where not too long ago there were 7) doesn't have time to reconfigure the files. Also, all of these applications are legacy (VB 6, .Net 1.1, etc.) and most use Oracle as the db, not SQL. This might help from a development side, but we really need a TFS solution.
Can someone at least tell me if we're covering the basic functionality available for TFS or if I'm missing something really straight forward that would help?