Perforce in a Microsoft Shop

Question

Our dev shop currently uses Visual SourceSafe. We all know how that could end up (badly), so we're investigating other systems. First up is Perforce. Does anyone have experience with using it and its integration into Visual Studio (2003/2005/2008)? Is it as good as any other, or is it pretty solid with good features, comparatively?

Answer 1

I have experience using a Perforce derivative.

It seemed hard to manage from the admin's perspective, but it was fine to use from a programmer's perspective.

Then again, I'm big on command line version control so can't speak for VS integration.

Answer 2

I used Perforce at my last 3 jobs (my current job I'm using Subversion, which I don't like nearly as much.) I'm a big fan of Perforce, and moving from SourceSafe it will seem like Nirvana. Just getting atomic checkin will be a big boost for your company. Otherwise, Perforce is fast, it has good tools, and the workflow is simple for doing things like merges and integrations. I wholeheartedly recommend it. It may not be all new and flashy like the latest distributed VCS's, but honestly, I prefer the client/server model for its speed, especially if you're working with people in other countries that may have slow connections to you.

The Visual Studio integration is pretty good, but it has a few irritating issues. If you run another Perforce client at the same time (like P4V), it's very poor at keeping changes from the other client in sync in terms of showing what files are currently checked in/out. You generally have to shut down Visual Studio and load the project again if you want it to sync correctly. But, the sync status doesn't actually affect checkins/checkouts/updates from working correctly, it just means you can be fooled in to thinking something is in a different state than it actually is while you're in Visual Studio. The Perforce clients will always show the correct status as they sync continually with the database.

Also, on occasion you'll find you need to work "offline" (not connected to the Perforce database for some reason) and when you load the project again the next time, your Perforce bindings may be lost and you'll have to rebind each project individually. If you work with a solution that contains many projects this can be a big pain in the patoot. Same goes for when you first check out a solution, binding to Perforce is needed before the integration occurs.

Answer 3

I haven't used Perforce, but I have found moving to Team Foundation Server as one of the best options while working with Visual Studio.

Answer 4

Perforce works fine with Visual Studio, including "offline" mode where VS will make your local files writable and sync with the server later.

I tend to use the Perforce GUI for many operations (submits, diffs) just because it's quicker/better, but the process of the IDE checking things out is seamless.

Perforce in my experience is rock-solid and the best mixed (code+data) version control product out their if cost is not a factor.

My biggest gripe is that the performance of the server under Windows is no where near as good as under *nix, and if you are using a *nix server they do not officially support the option for case-insensitive filenames (meaning you either forgo support relating to filesystem errors, or setup a trigger that prevents people adding foo.cpp if Foo.cpp exists).

My other main compaint is that for some common operations you have to revert to the command line, often piping functions together. One example would be getting a list of files in a directory that are not under source-control.

Both of these are issues that reflect more on the company than the product though. IMO Perforce know they're at the top of the market and thus see no reason to invest in fixing things like this.

Answer 5

We used Perforce for well over a year before switching to SVN recently. While I did like the tools (for example, visual diff and merge and the admin bits), we had some really tiresome issues with binding, as Chris mentions; otherwise, the VS integration is satisfactory. If anything, I find working with SVN easier and more intuitive than Perforce. TortoiseSVN (the Windows Explorer shell extension) is great, and we bought a couple of VisualSVN licenses for VS integration. Contrary to Perforce, VisualSVN does not work with the MS SCC interface, but rather directly with the SVN client, which I personally see as an advantage. Perforce does have support for many other OSes, but our non-Windows devs feel more comfortable with SVN too. If I were to have to choose again, I'd stick with SVN.

Answer 6

@Frank Krueger: what perforce derivative?

Answer 7

Sourcegear Vault is the best SCM for migrating VSS users to.

And its cheap.

Answer 8

I've used personally and managed a number of teams for a few years who have been doing Perforce & Visual Studio. It works perfectly well. There can be a couple of binding/rebinding gotchas, but these are generally easy to sort out - Perforce knowledgebase and/or the mailing list is a good source of info.

Never had any problems with using command line, visual clients, and VS IDe simultaneously - refresh normally works fine.

Answer 9

We use perforce extensively in the company, including branching for very large projects, development on Sun Solaris and Windows, and more than 120 users.

It is very fast, and the Windows GUI (P4V) is very nice. The Explorer integration is acceptable. I've disabled the VS integration, and use macros (calling e.g. p4 edit) to edit/revert/diff files. The VS integration is extremely annoying for large projects (our solution has >130 projects), but may work for smaller projects.

Answer 10

It's difficult to call $900 per user a good feature.