An issue in managing a code base is not only to guide different developers through the development process, preventing that they overwrite each others modifications on the source code (which would for sure happen when just sharing the code files over the normal file system.
Never do that!!). But another extremely important point is to track bug fixes which represent extremely useful information. I'm sure you already experienced situations like the following. You develop some application, after some testing phase it goes into production. Feature requests and bug reports come in which you implement/fix. Then after some month again a bug report comes in, related to some of the bug fixes/feature implementations you did previously. And then, if you're lucky you remember why these changes happened and if you're excellent, you may even remember the exact feature request/bug report given by the customer. But I'm sure, if it was just a bug you fixed in 5 minutes you will not be able to remember exactly.
And here's where you need good tools. Luckily, Visual Studio Team System (if correctly used) provides you already a lot of tools for helping you in managing these kind of information. I'll show you an example, I experienced today.
A bug report came in. So I started the application and tried to reproduce it. It was not really a bug, but more like an explanation request, why the program behaved in a certain way. So I took a look at the piece of code which cause that behavior:
When looking at the code, I immediately remembered that this code was written due to a previous bug request. But which one? Good question...
Well, if you did worked in a clean fashion previously, you can get that information in less than 20 seconds. You just right-click on the code, go to "source control" and then "Annotate":
A new editor window will open, containing the corresponding annotations on the left side:
As you can see, this change was about two month ago, so of course it is difficult to remember everything. So, you just click on the corresponding annotation link and the change set dialog will open.
Now you can immediately see the involved source files and if you wrote a meaningful comment you may even immediately recognize the reason for this change. But you can even go further. If at the time of your commit when you fixed this bug, you associated the related work item, which has been entered by your customer on the Team Foundation system (of course this is a precondition for all of this here), then you can view this item now, with the customer's description, all of the history with your comments etc..:
And that's great I think. So it is worth to take this 2 seconds more and to associate the related work items (if available of course) when you commit your code.
As already mentioned, a condition for being able to work in this way is that you have all of your bug reports and feature requests as work items in your team system. Now the best way of course is to instruct your customer appropriately s.t. he's able to create these work items over the TFS web interface. If that's not possible, you either have to do it yourself when you get a bug report (this is however inconvenient and time consuming) or there is some intermediate help-desk person which creates these items.
Questions? Thoughts? Hit me up
on Twitter
