Remote developers use one repo, we will use our own to build and deploy

Question

Good Day. here is our requirement. We have a team of remote developers who use their own svn repository. They are committing all changes to /trunk. We want to grab a nightly snapshot of their repo and import it into ours. We want to create branches and tags to identify the releases and we will build and deploy on our side.

Initially, I thought to use svnsync, but not sure if that is the correct tool as the build will create new files (which won't need to be committed back to the remote repo). Also, our tags and branches will not need to go back either.

It seems like we want to do a commit from their repo to ours and then be able to manage our repo, business as usual. Bad idea? Bad implementation?

Answer 1

I assume you don't want to either extend their repository to include your build/working area, or open your local repository and have them commit their changes to yours; presumably the remote team are a contract resource (or similar) who have their own working practices and you simply want to build overnight from their latest version of the source.

You could make their repository an external resource to your own, I suppose - essentially you'd build a 'dummy' project which had a reference to theirs - or use the hotcopy function to take a 'live' snapshot of their \trunk and then import that into your own repository...

Answer 2

SVN is a centralised repository. It's not designed to have changes applied in multiple repositories.

With git (or mercurial, or bazaar, etc) this model is the natural way of working, so if you can use one of them, do so.

If you can't use them completely, you can still use git-svn as a compatibility layer. Your remote developers would then use git and you'd pull in changes as required.

But if you're committed to SVN, it would be much better to allocate a branch (or set of branches) in your central repository for the team to commit to.

Have a look at why you're thinking about multiple repositories. If it's due to latency issues, perhaps a write-through-proxy might be a better solution. If it's security/control, SVN allows you to manage authentication and authorisation pretty well, especially if you're hosting through apache.

Answer 3

As pointed out by Jim, distributed version control would be the way to go. However let me try answer your question with svn.

As you mention that the commits are going to be happening only with the developers at the remote place, why not just use the same repository checkout a working copy and perform builds on the same ? If you are trying to address network performance then you would want to use svnsync coupled with write-through-proxy. The below SO link has some detailed answer on the implementation.

http://stackoverflow.com/questions/2286586/mirror-svn-repository-write-through-proxying

Also you can look at SVN edge their roadmap tries to achieve something similar to what you are looking for.