The ideal setup for any versioning system would be to have the server on a dedicated machine with automated daily or weekly backups based on how often you make critical changes. At the end of the day you can use whichever you like so long as you use one because if you lose all your work or cannot revert to a previous working version of your code you have no-one to blame but yourself especially since they are all free and well documented.

I have met plenty of people who swear by GIT or SVN and will probably try to convert you if you enter a conversation about which is best. Perforce is not the only free system you can use for this purpose with other popular programs such as GIT, Subversion (SVN) and Mercurial all performing the same basic functions each with its own pro’s and con’s. A system like this also serves as a backup in the case of system failure or human error and as a time machine to find where an issue was introduced. This is very useful for tracking bugs and issues within code and assets. This allows you to go back in time and check the differences against previous versions of the same files. The idea behind versioning (source control) is to create a base revision of all your files and for each change you make keep a version for that too. This is only an introduction to setting up the Perforce version control system for managing your games code and assets. I will only be covering what I think are the main features of Perforce and what is most useful for Game Developers. This tutorial is written in a generic manner so as that you can learn to use Perforce on any project you have regardless of Engine, API or SDK.

The perforce visual client