Ship It! - 2.2 Manage Assets

You should have everything you need to build the entire product; if you don’t, then perhaps you aren’t using the tool properly.

Tip 3: If you need it, check it in.

If you can generate it, then don't check it in.

• pick an SCM
• learn how to use it
• generate a single-page quick-start guide that shows how to use the system for common operations
• show the system to your team and make sure everyone is comfortable with it
• import your code and supporting files
• start keeping all your files in SCM

Am I Doing This Right?

• Are you actively using the system?
• How long would it take to get a new machine up and running?
• Can you perform SCM operations quickly?
• Are you backing up the SCM's repository?
• Can you check out the entire project?
• Can you look at the differences between local edits and the code in SCM?
• Can you view the history for a specific file -- who changed this file when did they do it?
• Can you update your local copy with other developer's changes?
• Can you commit your changes to the SCM?
• Can you remove the last changes you pushed into SCM?
• Can you retrieve a copy of the code tree as it existed last Tuesday? 

I agree that an SCM is extremely important to a project and it is probably software suicide not to use one.  One area of tension I've run into regarding the "if you need it, check it in" rule was around libraries.  One project I worked on stored any dependent libraries right next to the source which was great.  The build was easy to reproduce, partly due to this fact.  As the project grew and many releases went out the door, our disks started filling up -- fast.  For each branch you checked out you got a new copy of log4j plus the 800 other libraries.  Developers checking out over slow WANs really complained because it could take hours to move files around.  I suggest thinking about what happens when you start branching your code as you implement the "if you need it, check it in" rule.