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?

I've used several SCMs over time, including SCCS, RCS, CVS, SVN, Perforce, and ClearCase. Subversion has it's faults, apparently, but it's been so long since I've seen one that I forgot they exist.

On to the subject of this entry. Perforce sucks rocks through straws.

We've been porting a project to Maven, an Ant project stored in Perforce. Having done this once with an Ant project stored in Subversion, the process was simple: Create a branch, issue the svn copy commands to populate the branch (copying groups of files as needed to the new directory layout), then when the branch is working satisfactorily, push the branch back to trunk.

Perforce, in it's infinite wisdom, has the broken concept of "integrate" with two variants: So called "file spec" and "branch spec". If you read the Perforce docs, the difference is about as transparent as roofing asphalt, but when you get down to it, you find that a branch spec is essentially a record of all the file spec used to create the branch. The problem is you have to do this completely correctly before you use it, or you have to blow away all your files and start over, every time you change the location of the destination.

The Subversion user will casually say "duh, well, use a file spec". Unfortunately, file spec (instantiated via direct 'p4 integrate' commands in a CLI or dragging files in the GUI) are not persisted. One can look at the history of a file and see that it was branched, that the corresponding file in trunk has lots of changes that you want to grab, but you can't *do* anything with the information. It's just metadata.

Fools! People are still working on the trunk, and I need their changes. WTF good is branching in SCM if I can't have the tool use the metadata to grab changes on the trunk and apply them to the branch? As best as anyone here can tell, that's not an option unless you excruciatingly visit each branched file and ask Perforce to kindly move the change across.

Or use the aforementioned branch spec. There are about seventy distinct moves of files needed for it to recreate the new (saner) structure required for Maven. Generating that list would be impossible as some kind of stream-of-consciousness blurted out into a ten-line window in the GUI.

This is insane.

Arguably, this is a minor inconvenience compared to the next problem. Imagine we've got our branch working, we're ready to adjust trunk to match. Is it even possible? No. All it appears we can do is push the contents of the files in the branch back into the existing structure of the trunk, since a "reverse integration" simply means use the contents of the filespec in reverse. Or am I expected to write scripts to do this? It's certainly not outlined in the Perforce User Manual, but if I go to http://svnbook.red-bean.com/ I find these exact use cases outlined with clear steps.

It's been said that there are a lot of commercial software projects that have been made irrelevant by superior open source projects. I remember being fond of Perforce a decade ago. Today, I am spoiled by Subversion. I feel bad wishing that Perforce would go out of business soon, but I can't help but wish this scourge of an SCM finds the dustbin of history as soon as practical.

Yes, this is probably very naive. But wouldn't it be great if Automake was updated so that it could generate the spec files and build targets required to create RPM and SRPMs? Then you could install the software using RPM, and uninstallation and upgrade would be much cleaner. As well, it would be a lot easier for the maintainers such as Axel Thims. Or maybe this exists already in a different form?

Well, I just got the trusty orb.org domain back online, and guess what? Seems a lot of people have (mis)configured their SMTP MTAs to ask me whether an address is an open relay!

I never thought to be a submitter to SpamCop, now I see why to do so.