Visual Assist, Incredibuild and Perforce
Hi,
This is my first post on C++ since the web-development foray. I’ve started working with Beautiful Games Studios on the latest Championship Manager 2009 game. I’ve a few musing since I’ve started.
Visual Assist is the best resource I’ve ever used for Visual Studio, I think our studio has a studio wide license for it and its very much recommended. It provides a far superior intellisense to the built-in one and jumping to and from header/cpp files is very handy(using Alt+O shortcut). It also provides excellent code suggestions for variable names and function definitions. The various shortcuts are great. As the project we’re working on is quite large, a change to a header file and trigger a recompile of almost the whole project. Doing this on a single machine would take ages so we use incredibuild. Incredibuild distributes the build across other computers on the internal network and across your machines CPUs and so the compile time is reduced from hours to minutes.
Perforce is our source control system. Having previously used CVS and SVN I thought it would be easy to figure out. It proved more difficult than I expected as it uses changelists which I wasn’t familiar with, client specs and has other ‘features’ that took me a while to figure out. Syncing and updating you code base can be messy if you have lots of stuff checked out as you need to resolve new changes with your own local changes. However it forces you to check stuff in often. One of the biggest annoyances with its integration with Visual Studio however is when you happen to have a vcproj checked out. Occasionally Perforce will check out a vcproj for no apparent reason whatsoever. If you didn’t know this and perform and update then you can miss new files that have been added to the project if you don’t resolve your vcproj. This will of course throw up a lot of errors next time you compile and can be mysterious unless you figure out there was a vcproj checkout.
From this and for other reasons I’ve figured out one rule of thumb with Perforce. Always check your changelists (refreshing each one of them) whenever you update(get the latest version) or integrate across branches. That way you’ll pick up what conflicts exist and can resolve them and you should be ok.
Another problem I’ve found is that when a change in a vcproj is detected, Visual Studio asks you to reload the project. Obviously you’ll want to do this, however Visual Studio 6 never ceases to crash for me once I compile after reloading the project. So its a good idea to close down Visual Studio before performing an update. That way when you open it again Visual Studio will pick up the new vcproj settings and generally does not crash.
Finally client specs are another confusing aspect of Perforce. A client spec is basically your user profile which manages a section of code/resources you’ve obtained from Perforce. I didn’t quite understand what they were to begin but now I’ve figured out why you can have more than one client-spec. If you have a whole bunch of files checked out and integrate your branch with another(i.e. the mainline) to get the latest changes there can often be a lot of conflicts between your local changes that you haven’t yet checked in and the new changes on the mainline. The only way you can fix these conflicts is to merge your own changes with the new changes. Once this is done you can check in the merged file into the branch and the integration is complete.
However I regularly want to get just integrate to pick up certain changes on the mainline but don’t want any of my latest changes to be checked in. So the merge option isn’t a viable option in this case as you can only merge (meaning you will have to check in your latest changes), accept the source’s version (thus losing yours) or accept your local version (thus losing the source’s changes). Creating a new client spec is the solution.
The client spec is basically a copy of the codebase in a separate location. You use a new client spec for integrating ONLY and use the other client spec for working on latest code. When integrating you get the latest code into your new client spec’s default changelist. Resolve any conflicts there may be(as there’s no local changes made by you on this client spec then there will be fewer local conflicts due to your own changes) and then you can check in the default changelist into your own branch. So you’ve now integrated without having to check in your own latest changes, others in your branch can update also picking up the latest changes and you still have your own latest changes intact.
In your other client spec you can now just update your code base and get the latest version. You could get conflicts but once those are resolved you can just continue working. You don’t need to check in your own changes to integrate the branch with the mainline. It may sound convoluted but is actually very simple and much easier than use than a single client spec. I found this out the hard way by spending about an hour trying to back out of changes I had made by backing up the files locally, reverting them and then integrating. Then I would open up the backed up files and re-apply my changes, very messy you’ll agree!
