Recently in Perforce Category

Oh no! Not another perforce post. Spare us. We're not even using perforce anyways. Uhm. Have those guys left? Ok, well then for the rest of us that are left, I'm going to assume that you either use perforce happily at work or you are forced by some guy to use it. If you're the latter, then you might look envily at other modern source control systems that literally run circles around this old beast. I'm not kidding, running circles really means that you in other systems have adopted branching as the most basic operation you do.

The source control history is a precious asset. How your source code evolved over time, what and who made the changes (and why) are questions that can all be answered by the history. It's important to try to preserve the history, but it's also very easy to forget and not do it. It is very frustrating to do some detective work only to find out that the trails end cold when someone copied the file without telling perforce. Best of all, the person who did this might have quit and you have now no clue as to where that file originated.

I guess I made the last post a little bit of a holy crusade and while I guess that is just fine for a blog like this I did just throw it out there that I hate the non windows look and feel of the p4v application without any motivations, so I decided to just download the thing and rediscover how crappy it still is and write it down this time.

Perforce have had a strange development over the last couple of years with their UI clients. Perhaps not so strange from a manager's perspective or even a marketing perspective...

How do you use perforce? Some like to stuff as much as possible in the repository, in the hopes that it will be useful to have it all in one place. Others like to keep it minimalistic as to not bog down the server too much. I've already written a little bit about the things that might be good to consider setting up a perforce server, but once it's up and running you might want to have a look at how you are using it.

I'm a big fan of continuous integration, small checkins and very quick checkins. It's easier to debug afterwards and trying to puzzle together from perforce history afterwards is much easier when the changes are small and atomic. Now, that's what I like to do. Sometimes things don't really work out in the real world like you want it to so the other day I found myself with the fun situation of having two weeks worth of changes to try to integrate back into the main line. Of course nothing was backed up, nor did I feel particularly worried about it at the time. I had however done a lot of work, some of the changes involved the fruits of heavy thinking and other changes were the result of an hour or two of menial changes to the code that was a result of some other change.

Sometimes you wind up with changes in your source control system that shouldn't be in there, or you hit the submit button in perforce when you really meant just update the description. Anyways, you find yourself with a changelist that you want to roll back...

Visual Studio is the tool that most games programmers come to use for their day to day work. Perforce also seems to spread amongst games companies as the SCM system of choice. On paper Visual Studio also have source control integration. Great, now everything just happens automagically! No need to think about those mundane issues, I can just concentrate on the code. Well, that's wrong. You do need to concentrate on the "mundane" issues. One of the things that annoys me to no end is the fact that when you have the SCM feature enabled the time it takes to open a solution...

One of the annoying things about perforce is the need to be connected to the perforce server at all times. Manipulating files underneath perforce is a recipe for a world of hurt and pain. But there are times when you want to do just this, say you're on a trip with your laptop and of course there's not WiFi hotspot where you are just now, but you still want to code something and later on check it in.

I'm sitting here in my apartment amongst boxes and boxes, still unpacked from moving from San Diego. Moving is always a pain and this time is no exception. Packing all your stuff takes some time and unpacking takes even more time since you have to figure out where to place stuff, now in the new place you don't really know where everything goes. Speaking of packing and unpacking (nice dissolve, eh? :) doing the same for your changelists in perforce should be a breeze. The command 'p4 diff' actually outputs some interesting information, amongst them a full description of the differences of the currently checked out files. Unfortunately the output is not trivial to reapply again. Well to the rescue comes two little python scripts!