Can I have one project in two SVN repositories?

Question

Our I.T. dept doesn\'t allow connections to the SVN server from outside the physical office. (They\'re just kind of like that.) I need to work on projects when I\'m not at t

Answer 1

Look into svnsync. I use it to mirror an SVN repository on source forge to a personal box so I can use Trac with it.

http://svn.apache.org/repos/asf/subversion/trunk/notes/svnsync.txt

It's very easy to use, and you should be able to set your office repo up to sync to a personal repository.

Answer 2

Short answer: no. You can't share history between repositories.

The long answer: This is a weakness of centralized systems like Subversion. Distributed version control solutions (like git) don't have this problem. Each "working copy" is a repository and commits can be made off-line and synched between repositories (or to a central "official" repository) at a later time.

What you'd need is some way to work locally on your computer with a local repository and sync changes back and forth when you are able. It just so happens that you've got a few options:

• git includes git-svn which provides this kind of functionality. git has a learning curve, but this has improved with the 1.6.x series.

• svk no longer seems to be very actively developed, but it does work reasonably well.It works very much like Subversion. It allows you to keep local mirrors of your official repositories, make commits to local branches on them and push those changes back to the official repository when you are able. It's not truly distributed in the same sense as git, but it's probably a better fit for your situation and less of a conceptual change than git.

Answer 3

It is not practical for Subversion alone, but it is practical in distributed versioning systems such as git.

Have a look at git, and more importantly git-svn.

Answer 4

I made a blog post about how to do something similar recently. I think this will work for you, except you will need to sync from your work place, unless you can tunnel through via ssh.

http://justinsboringpage.blogspot.com/2008/11/how-to-copy-svn-repository-from.html

Subversion has a tool called SVNSYNC to make it easy to sync from one repository to another. This is great when moving to a different web based server. In this example I'm copying a project I work on from Sourceforge to Google Code. Once done, the google code repository will be an exact mirror, including the complete change history.

You also need to set the revision number of the repository to zero. Google code, predictably, makes this easy, by having a button on the source page to do it for you.

You need to have your username and password for google code to do this. For the repository you're copying you don't. First you use the initial command to set things up for the copy, then use the sync command to do the actual copy. It does this one revision at a time and takes a while...

svnsync init https://lispbuilder.googlecode.com/svn https://lispbuilder.svn.sourceforge.net/svnroot/lispbuilderProject svnsync --username YOURNAME --password YOURPASSWORD sync https://lispbuilder.googlecode.com/svn https://lispbuilder.svn.sourceforge.net/svnroot/lispbuilder

Answer 5

In svn you can definitely set up a couple of repositories and then tie them together with the svn:externals command. I'm at home, so I can't remember the full details, but it's similar to using modules in CVS. You create a folder and set the properties on it to be a whole bunch of externals (that map to other higher folders in other repositories).

The ugly bit is that its messy to create branches and final versions, since the final folder with the properties isn't treated very well in the repository, but other than being a bit awkward it works well enough. We have the base code in one repository, and two other ones with instance-specific configurations. Checkout the right tag, and you get a fully merged project, ready for hacking. (It did work way better in CVS, yet another useful feature lost in time).

Paul.

Answer 6

You need a Subversion replication system, such as Pushmi, or SVK as mentioned. If you can connect through your webservers, why don't you set SVN up with http access instead of svn? If ports are blocked, you can use mod_proxy to rewire a public url to the internal svn port.

However, if you're having to fight your IT department, then its all gone wrong already. You need to engage with them, preferably officially, to get them to support whatever policies you need to do your job. If you find yourself bypassing their systems, you're either going to get into trouble (eg. there may be perfectly valid reasons your corporate says no source code access outside the company, and its a disciplinary offence to do what you're trying) or your managers need to be made aware that IT isn't working for you.