Remote Subversion Repository

Question

My current project has it's master Subversion repository located on a network with restricted access. Most of our developers have access to this network and have full functionality with the code base. I currently have 1 "remote" developer that does not have access to the network. The way I currently manage this is to check out a working copy to a fresh workspace, zip it up and send it off to him to work from. Upon receiving each code dump from me, he puts it in a local Git repo to give himself some version control. When finished with a set of tasks, he zips it back up and sends it to me, and since it still contains the svn metadata, I can synchronize with the repository and commit/merge his changes. And then repeat. This is a huge pain for me, but it is manageable since I only do it for 1 person.

We are currently looking into the possibility of adding several more remote developers that would not have access to the restricted network, so I am looking for alternatives to my current situation. Ideally, I would like to have a remote repository that essentially acts as a branch to the master repository. I've read about svnsync to create a mirror, but it doesn't look like you can commit to the mirror or from the mirror back to the source. I will need to be able to commit to both repos, merge, and reintegrate. I am not opposed to switching from Subversion to Git, but I would like to reserve that as the last solution.

Any suggestions are welcome! Thanks!

Answer 1

We have a similar setup but using the following:

SVN as the master repository git-svn repository which does two way communication Each remote worker has a git repository and pushes to the git-svn repo

The git-svn repo can then update the master repository, the only person with control over the git-svn repo should be yourself and access to it should be secured as normal. We have found that this works well and allows us to keep the main SVN repository private while allowing remote workers to commit.

Answer 2

It sounds like migrating entirely to Git is what you want to do. I would suggest that you take a look at How to use git-bundle for keeping development in sync? . The workflow pattern in that answer seems to be similar to the situation you're describing.