Recently, we came across the requirement to develop using our own subversion repository, while updating the client’s repository every time an iteration completed and delivered.

Our initial thoughts were pretty much pessimistic, with doubtful merges and lots of manual work. Fortunately the following worked without any problem:

Create two working directories:

• the master one, linked to the internal svn repository. All development takes place in that working directory. Assume that the connect string is something like svn+ssh://user@server/svn/repo1. If necessary do a checkout from that repository: svn co svn+ssh://user@server/svn/repo1
• the client one, linked to the client’s svn repository. Assume that the connect string is something like svn+ssh://clientUser@clientServer/var/svn/clientRepo1. Perform a checkout the first time to make sure the repository location is properly set: svn co svn+shh://clientUser@clientServer/var/svn/clientRepo1

At the end of an iteration, commit all the changes from developers working on this iteration. It is assumed that this would be the version delivered to the client for further testing.

Now move to the client’s directory and perform an export from the internal repository, using the following operation: svn exp svn+ssh://user@server/svn/repo1. That will bring the latest version of the internal repository to the working directory linked to the client repository. Then, just by performing a simple check in we update the client’s repository with the latest change: svn ci.

The above process works well only in case the client is not performing changes to the repository simultaneously with your team!If this is not the case, more work is required to get those changes back to the master repository!

It may also be used for occasional snapshots of the master repository to guarantee against its potential failures.