The bigger picture

Perforce is cool. Really cool. Sure it may be centralized, require a network connection all the time and have a strange commit flow (yes p4 open, I am looking at you). However the GUI client is fantastic, the CLI tool excellent (with well thought-out command names), p4 help almost always saves the day, the documentation is great, the technotes can be a life savior. And to add to that they offer a proxy. A perforce proxy is no substitute for a distributed SCM (since in turn it must be always connected to the main server), does not automatically mean that user experience is identical as if the main repository was on the local LAN but is a welcome add-on.

Lately people noticed our perforce proxy being rather slow. Admittedly it’s an old machine, with a measly (for today’s standards) 512MB RAM. So what was the verdict? Let’s buy a new one! YEAH! And let’s make sure that it can expand to 32GB, the entry level model that grows to “just” 8GB are probably not enough.

I am frequently impressed by how often people end-up getting confined in their micro-world and fail to get the big picture. Good product QA engineers, who could be great if they would get a better understanding of the underlying O/S. Same for development engineers. Customer support engineers who have an excellent grasp of the customer and provide prompt responses for documented issues but with poor troubleshooting skills, resorting to product development engineers for the slightest of problems (this is not an excuse for poor documentation btw). And the list goes on.

For what is worth, per the Perforce technical notes 8GB would probably be a little bit too much for the new server. 512MB would be more than enough. With a careful setup (disabling unnecessary daemons of the underlying O/S) even 256MB could suffice (and yes this means that we may not need to buy a new server)