Best practices: multiple developers working on the same project

PHP, PHP Code Generator, PHP Form Generator, Tutorials

Many developers have the need to work collaboratively on the same ASPRunnerPro or PHPRunner project. In this tutorial I’ll show how to make this happen with almost no effort.

We are going to utilize the power of version control system (VCS). Version or revision control systems track and provide control over the changes to the source code. The most popular VCS systems nowadays are Subversion, Git, Mercurial and Bazaar. We plan to use Subversion (SVN) which is easy to get started with.

I’ll cover the bare minimum you need to know about SVN in order to start. For in-depth tutorial check SVN book.


We are going to need some additional software.

1. Server software

You need to install SVN server software on some server machine. We recommend to check VisualSVN. It is easy to install and configure.

Another option is to use a hosted SVN solution. There are quite a few of them like Unfuddle and CodeSpaces. Besides SVN they provide project management tools, bug tracking and more. In this tutorial we’ll open a free basic account with Unfuddle which is easier than managing your own SVN repository. You can upgrade to a paid plan at any moment.

2. Client software

We recommend TortoiseSVN client. It installs as a Windows explorer extension and available via context menu in all explorer windows.


Before we proceed with step by step tutorial lets consider a typical scenario that involves two developers working on the same PHPRunner project.

  • Developer 1 creates the project and makes some changes
  • Developer 2 gets the copy of project, adds a new table, makes a few changes in visual templates
  • Developer 1 gets the updated copy of the project and sees all changes made by Developer 2

And here is the picture that tells it all.

SVN workflow

Step by step tutorial

Lets get started.

1. Create a repository

Create an Unfuddle account. Create admin user. Proceed to ‘Repositories’ to create a new repository.

Creare repository

Note the URL of your repository ( in our example).

2. First checkout

Create a new PHPRunner project. Open project directory in Windows explorer (i.e. C:\Users\Sergey\Documents\PHPRunnerProjects\Cars). Right click anywhere on blank space in Windows Explorer and choose SVN Checkout ….

SVN checkout

Enter the URL of your repository. Checkout directory needs to be the same as your project drectory (C:\Users\Sergey\Documents\PHPRunnerProjects\Cars). Click Ok. Enter username and password.

If checkout is successful you will see a hidden .svn folder created in your project directory.

After first checkout

3. Developer 1: Adding PHPRunner project to SVN

Make changes to your PHPRunner project. Add a few tables, make some changes in Visual Editor. Save your project.

In Windows explorer select the all folders except visual, tmp and .svn and project file (.phpr). Right-click on selected files and choose Tortoise SVN->Add. Make sure all files and directories are selected.

4. Commit

Once files are added – right-click in the same folder and choose SVN Commit …. Make sure to add some comment.

SVN commit

Congratulations! Your files are one the server now. You can logon to Unfuddle account and view your files there.

Revision 1

5. Developer 2: Checkout

Now second developer comes into the game. We want her to get a copy of the same project on her machine and make a few changes.

Once TortoiseSVN is installed we need to create a folder where this project will be stored. Once created, open this folder in Windows Explorer and right-click anywhere. Choose SVN Checkout ….

Enter repository URL and checkout folder. Enter username and password when prompted.

Note: we recommend to create a different user account for each user. This way you can track changes made by each developer.

6. Developer 2: Committing changes

Second developer makes a few changes in the Visual Editor and adds a new table to the project. Once project is saved she needs to add new files (if any) to repository.

In Windows Explorer make visual folder and PHPRunner project file selected and choose SVN Commit. Check off new visual files if any. Add a meaningful comment listing changes you have made. Commit.

Commit from second machine

Note the icons that TortoiseSVN adds to each file. The blue question icon means ‘not under source control’. The red exclamation point icon means ‘this file was modified’. The green check box icon means ‘normal’ status.

If you proceed to your repository at Unfuddle you can see that current revision number is 2. Each commit is associated with a new revision number.

7. Developer 1: Update

Developer 1 runs SVN Update in the project directory to get new files and updated project file.

SVN update

8. Profit

Developer 1 opens updated project file to see changes made by Developer 2. Mission accomplished.


Additional notes and questions

There are a few things that may require some extra setup.

Database connection

We need to make sure that database connection points to the same database on all machines. If you use a file-based database like MS Access the best approach is to put database file to the server and specify file to the database as \\server\share\database1.mdb.

In case of SQL Server, MySQL, Postgre or Oracle having a centralized development database makes even more sense.

Output directory

The same story – you want output directory to point to the same directory on all machines. Something like C:\Projects\ProjectX will work just fine for this purpose.

I’m the only developer, should I still use SVN?

Yes, we strongly recommend to use SVN or any other source control system even if you are a one person shop. It gives you both backups and ability to rollback any change made to the project. What else do you need?

What’s the difference between Checkout, Commit and Update?

Checkout – first step to get project files on a new machine. In most cases you only need to do this once.

Update – perform an Update every time before starting your work. You can run Update as many times as you want

Commit – commit changes you made. Commit at the end of the day or once you completed a large chunk of work. Run Update after Commit to incorporate changes made by other developers.

This is all you need to know in order to start using SVN with PHPRunner or ASPRunnerPro.

7 thoughts on “Best practices: multiple developers working on the same project

  1. Thanks Sergey! This is great. I’ve been dabbling with the idea of implementing version control even though I am currently working as a solo developer for my employer. I recently looked at unfuddled and github based on recommendations from friends who are experienced developers.

    I’m going to try the software you mentioned in this post and I’ll post any relevant feedback in this blog post once I’ve had a chance to play around with implementing SVN.

    Thanks again and keep this blog going… so far I have been very pleased with the materials you’ve added here. It adds another dimension beyond the user forums!


    Marcelo Ramagem

  2. Sergey,

    You are right on the money with this article. I am using for the SVN repository and I highly reccommend it for companies not running internal Source Safe environments. I do want to put my observations in on this as this is exactly what we are doing on the Rabalis project.

    This system of check in and checout works fine except when Developer 2 does not comment the code and does not use the ticket system or messaging to let Developer 1 know what changes have been made to what specific code peieces.

    Check in and check out are all good practices but communication is key in and between multi-developers projects. THe first try using this was a disaster as Devloper 1 would make a change then Developer 2 would over right the changes because one or the other did not use the upload download sequence properly. We found it best to dis-allow any 2 developers to be working on code at the same time on a phpRunner project. We still have 2 developers working one phpRunner project but now have mandated Developer 1 works from 9am-5pm then checks in the code and closes the ticket of changes he made then Developer 2 works from 6pm-12AM then checks in the code and closes the ticket of changes he made. Now we have soldid code that is not being over written because people can’t follow simple proceedures of checkin and check out or do not comment and track code changes. Developer 1 needs to know what Developer 2 did and visa versa.

  3. Sergey,

    I give a +1 on this post. We’ve been working with CollabVersion’s SVN and Tortoisse client for more than 3 years for all our developments (Delphi, MySQL DB, Visual Studio) for 4 developers . We have 1 server in place, and would like to go with the same environment for PHPRunner as well, even though there would be only one developer for php and 1 for html/web gui.

    By following your advice, exchanged with some emails, we finally commited all of our PHPRunner based projects to the same SVN server.

    Now we are able to commit/update our projects, and make sure all of our projects stay updated with changes made in various PCs, by all of our developers.


  4. I have a question on step 3. The text says to select all folders except visual, tmp and .svn and project file(.phpr). However in the image it shows selecting everything except .svn, output, and tmp. I am just curious on which instruction to follow. Any clarification would be greatly appreciated.


  5. It appears that this issue happens when a new page is created. Our repository is Fully Recursive, so any pages that are created should be included in the changes, but it doesn’t include the new page’s HTML changes.

    We found the solution, in case anyone else was having this issue. If you create a new page, you must right click in your project folder -> Tortoisesvn-> click “Add” in order to get new pages with HTML edits. You can do this automatically by adding hooks to Tortoisesvn. See this webpage:

  6. In the scenario explained, what will happen if 3 or 4 developers work on different features?

    Yes, each feature will hopefully have its own files, but the features will also update the “phpr” project file.

    How can we resolve the conflict in phpr project file?

    As I understand, the developers must plan to develop each feature and then update the phpr file and push, and others should wait for the update, and then pull the phpr (and all other files), and then begin working on feature 2 and so on…

    And if so, they cannot work on their own feature at the same time (parallel).

    Thank you

Leave a Reply

Your email address will not be published. Required fields are marked *