Jun 29, 2009 at 1:14 AM
Edited Jun 29, 2009 at 1:16 AM
Here's my check-in sequence:
1. Ensure your code builds, unit tests run without error, and that your changes work prior to check-in.
2. Do a Get Latest. Some people don't like this part because they are afraid of getting code that isn't compatible with thiers. However, it is always better for a single individual to resolve incompatible changes than to hose the entire team by checking
in code that doesn't build or is incorrect.
3. Ensure your code compiles, unit tests run without error, and that your code runs with code downloaded from the Get Latest. It's possible that some of your code doesn't work with what was in source control, so you'll need to resolve the issues.
4. Once your code builds and your changes execute properly, you can check in.
Assuming that each developer does the same thing, this sequence goes a long way toward ensuring that no single developer breaks the build.