Where, oh where are my bug fixes?
The Visual Studio and CLR teams are huge. If we were to all develop on the same code base simultaneously, we'd kill a lot of time because instability caused by one team's changes would affect the whole project. To remedy this, groups of developers develop against a specific "virtual build lab".
There's multiple virtual build labs, thereby allowing teams to develop against a code base without worrying about changes from other teams affecting the stability of their code base. Periodically, each build synchronizes its changes with the "main" build lab. This is when:
- The main code base picks up your build labs changes
- Your build lab picks up changes from the other build labs
The frequency of these integrations is on the order of a few weeks. See the release_team blog for more specific details of the process.
Conceptually, this Virtual Build Lab system works fairly well. However, sometimes you absolutely need a change from a team that's in another build lab. In order for this to happen, both you and the other lab's code have to be synced against the main build lab.
The upshot is that sometimes a fix made by one team won't be propagated to another team's code base for quite some time. Currently we're waiting on some stack walking changes made by the CLR team a long time ago. The way around this (if you're lucky) is to take just the changes you need from the other build lab's code base and integrate then into your build lab. Often times though, a change can't be confined to a small, reasonable set of files.
I can't help but wonder: Is there some better way of doing software development on massive projects with many teams? Specifically, is there a way of getting important changes to the right teams faster, while not compromising the overall stability for all teams?
Comments
- Anonymous
January 19, 2005
Branches? - Anonymous
January 19, 2005
The comment has been removed - Anonymous
January 19, 2005
The comment has been removed - Anonymous
January 19, 2005
The comment has been removed - Anonymous
January 19, 2005
The comment has been removed - Anonymous
January 20, 2005
The comment has been removed - Anonymous
January 21, 2005
At my previous employer, we were using subversion for version control, for about a year or so. It seemed to support alot of the branch and merge scenarios Dr. Pizza mentioned. Once I "got" the way subversion is all based on transactions, it became easy for me to conceptually understand what was happening in a merge or a branch. I never "got" that with other version control systems I used in the past.<br><br>As I understand it, Microsoft uses "Code Depot", which is a homegrown version control system, simmilar to CVS? I have caught a few glimpses of some pre-checkin script tool or something. Obviously some time is spent maintain this tool set (the version control tool set.) Perhaps someone should make a tool to help with cross branch merges. - Anonymous
January 25, 2005
I would think that if a rule such that each fix had its own patch (or perhaps set of patches, if the fix needs a fix) were established and enforced then the granularity issue would go away. - Anonymous
January 26, 2005
re DrPizza 25 Jan 2005:
I may have obscured it, but that was exactly my point. One work area per fix/feature is one (albeit of several) ways to get a per fix/feature patch if the SCCS has change set functionality or some sort of 'auto label per checkin' feature is available.
IanC - Anonymous
June 04, 2005
The comment has been removed