In this example, a C programmer has the file Help.c in VSS and in his working folder. His compiler turns this source code file into the object module Help.obj. At any given time during the development cycle, both files, Help.c and Help.obj, can exist in the same folder. Each time the developer types MAKE from the operating system, his Make utility compares the date/time stamp of Help.c with Help.obj to determine if it should compile, using the following rules.
This behavior is simple, logical, and consistent, ensuring that every Make builds the entire program from the most recent version of the code as quickly as possible.
Now consider the ramifications for VSS. You compile Help.c into Help.obj, giving the latter a new date/time. If you execute Make again without changing anything, Help.c is not recompiled. Satisfied with your changes, you check Help.c into VSS; and the next morning, you get Help.c again.
If Help.c has not changed, VSS recognizes that its own copy and yours are identical. It does not perform a Get, the file date/time does not change, and the file is not recompiled, which is as it should be.
If another developer has changed Help.c, VSS recognizes that the file is different. It Gets Help.c, and sets the file's date/time to the current time (instead of the time the file was checked in). When you execute the Make command, the file is recompiled, again as it should be. Hence, VSS's behavior sends the correct signal to the Make utility regardless of whether anyone has changed the file.