For the last few hours I've been beating my head against why the build was broken. I couldn't believe that HEAD from Perforce was having so many issues.

Lo and behold, Perforce was acting stupid and was reporting the latest files had been checked out when in fact they were not. Hours were wasted. How could this happen?

The data about file version status (file metadata) is stored on the server. The Perforce server remembers that a certain directory on the filesystem of your machine has a certain combination of files in a specific directory. The *server* cares about *specific files* on *your machine*. Somehow, things happened to those files on my disk, old versions overwrote new ones. The server refused to acknowledge this until I forced it to overwrite all the files (which certainly defeats the reason to have source code control in the first place).

Imagine this analogy. Consider fifteen directories on your hard disk, all under source control. Think about these directories as rooms in your luxurious McMansion in the 'burbs. All the rooms have lights in them. Where are the lights controlled from? Switches near the door, naturally.

Now imagine a house where all these switches to all the rooms are all near the front door of the house, not in each room. If you want to go to the bathroom without peeing all over the wall in the dark, you need to go downstairs to the front door, turn on a light, go back to the bathroom, take a leak, then go back downstairs to turn off that light.

Now let's have a party. Besides the incredible congestion at the front door as everyone tries to find the switches for the rooms, they can't tell if they are changing the lights improperly because they can't really tell what the state of the room is (such as whether there is anyone in there).

The fix is simple. Put the damn switch inside the bathroom, on the wall near the door.

Does it make sense now why metadata belongs next to the files it serves? And why the server is a dumb place to put file status data for local machines?