Tracking Source Changes (All Check-Ins) The Build Process
There's a misconception among software companies that every line of code that they write must be protected like it's gold, but it's time for a reality check: Little source code is patentable or of real intellectual property (IP) value (see the "Richter on .NET Security" sidenote later in this chapter), so you should worry more about securing the source code control process and the build process rather than the individual source files.
Some companies go to extreme lengths to try to secure their source code via physical means, including locking developer machines in a secure development lab. These companies don't allow the developers to carry hardware or bags in or out of the lab. I don't know many developers who can work in that type of environment, though. Also, if you can't trust a developer not to steal your code, how can you trust him to write it?
There's a better way to secure your development:
These suggestions are representative of how we are able to track source code changes back to the original owner and how we are assured that only the changes necessary to fix the bug or add a feature are checked in. If you combine these steps with the VBL process in Chapter 2, "Source Tree Configuration for Multiple Sites and Parallel (Multi-Version) Development Work," you will have an incredibly reliable and dependable system of maintaining your sources and their changes.