Friday, June 12, 2009

Perforce listens to its customers

Perforce 2009.1 is entering testing.

There are enhancements to the server, to the command line clients, and to several of the specialized tools. In particular, I noticed:
  • There's a command-line version of the move/rename command: "p4 move". This feature, which is perhaps the #1 requested feature in the product (!) requires upgrading the server to 2009.1 also.
  • p4v has lots of new features, including "Reconcile Offline Work", which sounds quite intriguing for people who work disconnected routinely. We used to have to script this using the command-line tools; you can see how much the process has improved by comparing the P4V and command-line sections of the new Working Disconnected doc.
  • "p4 opened" now has a "-u" flag to look just for files opened by a particular user.
  • P4V now checks and prompts you if it notices that you are opening an older version of a file for edit. This is a nice feature, and may help people minimize their merging by helping them realize when they're not up-to-date with the server.
  • "p4 logtail" looks like it might be handy. Happily, our server is quite free from problems nowadays.
  • The server release doesn't appear to have any database changes. The database changes aren't common, but I always pay attention to them because they may require extra disk space and time during the server upgrade step.
I've always been impressed with Perforce's release notes. They are very, very thorough about describing exactly what they changed, and how it affects things, and their Technical Support staff is incomparable. You can always ask them questions if things aren't clear, and they'll answer straightaway. Perforce will even document internal changes that other companies would never tell their customers about, so you'll see entries in the release notes like:

#188212 (Bug #28268) *
Undocumented 'p4d -jds' crash fixed. This operation is
still not meant for regular production use.
Perforce are quite disciplined when it comes to rolling out releases; they almost always deliver a release every 6 months, with a short beta period open to all without any special restrictions. Because I don't generally need to live on the bleeding edge with our Perforce usage at work, I generally follow this simple strategy:
  • Read the release notes when the beta is announced, to get a feel for what's upcoming.
  • Wait until the release finishes its beta period.
  • Download the client software to my regular development machines (Linux and Windows) and start using it with the current server. I like to try to be the first person at my company to be using the latest Perforce client software, but I don't get so extreme as to run the beta clients, generally.
  • Wait another several months before upgrading the server software.
I usually find that I'm about 1-2 releases out of date on the server software, but that's OK.

No comments:

Post a Comment