To begin with, I want to tell you a story that I went through. I had pleasure to work with many teams and many tools. Every time we had to share files. I’ll describe those methods shortly and at the end I’ll show you a solution that in my opinion fits game development very well (especially Unreal Engine 4 projects :) ).

The story

There are many ways of achieving team collaboration. The easiest way is to use file system abilities like NFS or SMB. You don’t have to use additional software, just configure shares and use your local computer network. This works well only locally, but it’s BAD idea to open ports and share those protocols through the internet. If you have to, you’ll need to increase security by using a VPN or SSH tunnel.

On the other hand you can use cloud based solution like Dropbox, GoogleDrive or setup private one like OwnCluod. Both solutions allows you to access files through a website or use dedicated synchronisation software. This software can even store versions and recover deleted files, it’s good for office users that share documents or cat memes, but it’s not what we’re looking for.

If you really care about your project files and work convenience, you’ll have to use version control system. VCS allows you to store history of file changes, its multiple versions, performs file locks and merges or manages user credentials and access rights – with sensible security level. Currently, the most popular one is of course Git. It’s free, and has a lots of integrations (GitHub, GitLab) and client tools (SpourceTree, GitExtensions). It’s also distributed which means that you don’t have to install central server and be connected with to checkout files, because every user have full revision data and can become a server for others. This adventage is also a disadventage. The fact that you have all revisions stored locally can be harmful if you store binary files like assets (sounds, graphics, executables, libraries). Git uses snapshots, each file change makes a copy of it – your local repository will grow – It’s ok for small projects. If you want more you have to consider switching to centralized version control system. CVCS will keep all file revisions on central server, users will have only one revision stored locally.

TL;DR

To sum up, the question is if you choose to store gigabytes of data locally or stay connected and transfer gigabytes through the network ?

Decision

I’ve decided to choose second option. Good example of CVCS is Perforce (Helix). It has Unreal Engine & Visual Studio integration built in and it’s free up to 20 workspaces.

Assumptions

Now, let’s get to the point. There are my main assumptions.

  • I want to have my own Perforce server instance
  • I want my Perforce service to start automatically on system boot
  • I want my Perforce service to stop automatically on system shutdown
  • I’m going to use Linux

Problem

The easiest way of achieving this is to setup Perforce service as a linux daemon. P4D – Perforce Server binary can run itself as a daemon but this causes two problems:

  • Start and stop can be done manually
  • Service will be executed in context of user that log in

To solve first one, we can use init daemon. We’ll need to create init script and place it in /etc/init.d directory. This would allow system to start Perforce service on boot and stop it on shutdown. Then, second problem would arise. Init daemon executes other daemons in context of a root user which is not needed and can be concidered as a security vulnerability. To change user context, we’ll use daemon tool.

Prerequisities

There is no sense in rewriting Perforce installation tutorials so let’s consider those tutorials as starting point for our problem.

Starting point

So, our starting point is working perforce server. I’ve tested this on Ubuntu Server 14.04 LTS.

Configuration:

  • System user: perforce
  • System group: repo

Directories owned by perforce system user:

  • /repo/perforce/logdir – for p4err and journal files
  • /repo/perforce/rootdir – for database and versioned files

Perforce admin user: perforce (with password set)

At the end move Perforce executables:
mv p4 /usr/local/bin
mv p4d /usr/local/bin

Daemon script

Install daemon package:
apt-get install daemon

Create daemon script file:
touch /etc/init.d/perforce
chmod +x /etc/init.d/perforce

Fill in:

#!/bin/sh

### BEGIN INIT INFO
# Provides: perforce
# Required-Start: $local_fs mdadm
# Required-Stop: $local_fs mdadm
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Operations: start, stop, restart, status.
# Description: Perforce service.
### END INIT INFO

PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
. /lib/lsb/init-functions

# Log and journal files directory
p4journal=/data/perforce/logdir/journal
p4log=/data/perforce/logdir/p4err

# Database and versioned files directory
p4root=/data/perforce/rootdir

# Service params
p4port= # your network configuration here
p4pass= # your perforce password here
p4user= perforce

# Commands
p4cmdstart="p4d -d -r $p4root -J $p4journal -L $p4log -p $p4port"
p4cmdstop="p4 -u $p4user -P $p4pass -p $p4port admin stop"

# System settings
p4sysuser=perforce
pidfile=/data/perforce/pid

case "$1" in
start)
   log_action_begin_msg "Starting Perforce Server"
   daemon --pidfile=$pidfile --user=$p4sysuser -- $p4cmdstart;
   ;;

stop)
   log_action_begin_msg "Stopping Perforce Server"
   daemon --user=$p4sysuser -- $p4cmdstop;
   ;;

status)
   status_of_proc -p $pidfile p4d perforce && exit 0 || exit $?
   ;;

restart)
   /etc/init.d/perforce stop
   /etc/init.d/perforce start
   start
   ;;

*)
   echo "Usage: /etc/init.d/perforce (start|stop|restart|status)"
   exit 1
   ;;

esac

exit 0

Aftert all you should register created script for init daemon:
update-rc.d perforce defaults

Results

Now, Perforce server will start automatically with your system :)
Untitled3

You can still use commands manually:
/etc/init.d/perforce [start|stop|restart|status]
Untitled2

Enjoy :) !