Recently (just completed today), our group has migrated from Perforce to Subversion for source control of all of our automation test scripts and harness code. The decision to make the move was largely more for political and economic reasons than technical ones, but personally I do feel that for our specific needs, Subversion is a better overall choice. The advantages that we gain include:

• Cost. Perforce costs roughly $200 per user per year. With our group holding upwards of 30 licenses, this becomes a non-trivial cost. Subversion is open source and free. The benefit here is clear.
• Easier code sharing and collaboration between us and other internal Sun groups. Seeing as many of our tests can be used by other QA groups within Sun testing similar or identical products, Perforce licensing hurdles have started to block some of our collaboration initiatives.
• More flexibility when editing checked out code. One of my personal pet-peeves of Perforce is its requirement that you explicitly notify the repository that you are going to make a modification on a file before it allows you to modify it (i.e "p4 edit"). Not only does this prove to be a minor annoyance while editing files, it also makes it difficult to work on checked out code when you do not have direct network access to the repository. I do realize that there is a workaround for this problem, and I also realize the benefits of notifying the repository when code is being edited. In general, though, it makes the overall experience doing even simple tasks in Perforce cumbersome and somewhat unintuitive.
• Consistency between us and Andromeda/Galaxy developers as well as other Sun QA groups. In general, it seems that Subversion is the source control system of choice for many of the groups with which we are directly involved. Using the same system only make sense.

As far as disadvantages go, the one main pitfall that has been touted in comparisons between Subversion and Perforce is that Subversion does not have automatic branch tracking. Thus fundamental software engineering techniques of maintaining multiple branches of code and tracking and merging changes between branches is a considerably more manual and error-prone process in Subversion. However, since, as a QA group, we utilize merging features considerably less than a software development group would, I would contend that this negative has minimal impact for our purposes.

The move to Subversion is therefore a welcome one. With it, though, comes the minor overhead of adopting slightly different techniques when working with a Subversion repository as opposed to a Perforce depot. For the benefit of all, here are some basic tasks that many members of our group are used to doing with Perforce, along with their Subversion equivalents [Note these are guidelines for the Unix-based clients. I stay away from Windows as much as possible.]:

• Checkout code from repository:
  
  Perforce: The process of setting up a local workspace in Perforce always seemed overly complex to me. You had to set multiple environment variables (usually P4USER, P4CLIENT, P4PORT, but others configurable) to configure the repository location and user credentials. You then needed to setup a client workspace, mapping depot directories to local directories. After this process, "p4 sync" would check out a copy of the desired workspace for you.
  
  Subversion: Simpler.
  svn checkout --username [USERNAME] http://repository/location/and/desired/subdirectory [local directory]
  
  
• Update your local copy to the latest revision in the repository:
  
  Perforce:
  p4 sync
  
  Subversion: One step process.
  svn update
  
  
• Make changes to a file in the repository:
  
  Perforce: Two step process.
  p4 edit [filename]
  Modify the file as desired
  
  Subversion: One step process.
  Modify the file as desired
  
  
• Add a new file to the repository:
  
  Perforce:
  p4 add [filename]
  
  Subversion:
  svn add [filename]
  
  
• Delete a file from the repository:
  
  Perforce:
  p4 delete [filename]
  
  Subversion:
  svn delete [filename]
  
  
• Undo changes to a file in your local copy:
  
  Perforce:
  p4 revert [filename]
  
  Subversion:
  svn revert [filename]
  
  
• Check the status of modified, added, deleted, etc. files in your local copy:
  
  Perforce:
  p4 opened
  
  Subversion:
  svn status
  
  
• Compare a modified local copy of a file to the original checked out copy:
  
  Perforce:
  p4 diff [filename]
  
  Subversion:
  svn diff [filename]
  
  
• Commit changes from your local copy into the repository:
  
  Perforce:
  p4 submit
  An editor window using the program specified by the environment variable P4EDITOR will open for you to enter a description of the changes.
  
  Subversion:
  svn commit
  An editor window using the program specified by the environment variable SVN_EDITOR will open for you to enter a description of the changes. Alternatively, you can bypass the editor and enter the description inline:
  svn commit -m "This is a description of the changes"
  
  
• Create a branch:
  
  Perforce:
  p4 integrate [source_tree] [dest_tree]
  Perforce automatically keeps track of branched files. Therefore, merging changes between branches is more automated.
  
  Subversion:
  svn copy [source_tree] [dest_tree]
  As far as SVN is considered, once a tree is branched, they are completely separate and independent copies. After branching a tree, it is good practice to make note of it in the revision log so that the revision number can be found later when changes need to be merged with other branches.
  
  
• Move a file:
  
  Perforce: Two steps.
  p4 integrate [source file] [dest file]
  p4 delete [source file] In order to move a file in the Perforce depot, the source file must be branched and then deleted. This creates a somewhat counterintuitive revision history since instead of associating the entire revision history log with the new file, it simply points to the revision history of the originally branched file and maintains all history from that point forward.
  
  Subversion: One step.
  svn move [source file] [dest file]
  Under the hood, this performs the same copy, delete actions as the Perforce process. However, with SVN the entire revision history is copied to the new file since it does not maintain automatic branch information. For simple file moves, this is a more desired behavior.
  
  
• Resolve conflicts between your local changes and others' conflicting changes:
  If changes to certain files have been made since you last ran an "svn update", any conflicting changes that you have made to common files need to be resolved.
  
  Perforce: Semi-automated process.
  p4 resolve [file]
  Perforce will walk you through all of the conflicts between your changes and the others' changes and ask you how you would like to merge the changes. There is also the option to resolve the conflicts manually.
  
  Subversion: Completely manual process.
  After conflicts have been discovered (either when trying to do an svn commit or after an svn update), Subversion leaves three copies of the file in your local tree: filename.mine, filename.oldRev, filename.newRev. These represent your new copy of the file, the original checked out copy of the file, and the repository's current copy of the file respectively. At this point, it is up to the user to examine the differences between the three files and decide how to merge the conflicts together. After the file is updated to the user's liking, the following command must be run:
  svn resolved [filename]
  At that point, the newly resolved file can be committed to the repository.
  
  

There is a lot more that you can do with both of these source control systems, but for basic needs, this list is fairly comprehensive. An excellent online book that documents the complete feature set of Subversion can be found here: http://svnbook.red-bean.com/ and Perforce docs can be found via http://www.perforce.com