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 the office.

I could just check out the project and wait until I come in to do a check-in. Maybe that would be best. But I like to check in frequently. I'm wondering if there's some way I can keep a project in two repositories and keep them both up to date. That way I'd always be able to check in somewhere in case my HD dies. I have my own repository on a VPS server that I use for personal projects.

I investigated the svn switch command. With my current project in both repos I tried switching my working copy from personal to work SVN servers...

$ svn switch --relocate svn+ssh://personalvps.com/svn/project/trunk svn://worksvn/project/trunk
svn: The repository at 'svn://worksvn/project/trunk' has uuid '2baef97e-42ce-488c-bbba-c2625158c643', but the WC has 'f13e1f32-dc92-4c4a-b84d-34a59fe32063'

Then I tried adding the --username and --password params but got an error saying "no entry found."

Is this even possible or is it totally impractical?

---

UPDATE

Thanks for the answers. Unfortunately, any solution that involves action from I.T. (slight policy change, change a setting somewhere, install something) is not on the table. I have to find a solution within the current setup, which is no connections from outside except our Web servers.

I'll take a look at distributed version control.

Answer 1

Have you read about git? it uses a local repository for offline work, and can be easily synchronized with a svn repo.

Two articles that explain how to do what you want.

Answer 2

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 3

You could use SVN with another (local) repository on your laptop. Look for the popular git or SVK. These allow you to commit to the local repository first and then sync all commits to the main SVN repository.

Answer 4

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.collab.net/repos/svn/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 5

Take a look at Bazaar. It's rather less daunting than git, and has a useful-looking interface to Subversion repositories (via bzr-svn).

It will allow you to check out code from your Subversion repositories, develop independently (with local history), and check your code back in to Subversion as and when you need to.

Answer 6

I'd highly suggest your IT department set up a secure VPN, which would place you on their secure local network even when you're physically at another internet connection. It's incredibly tough to keep multiple-repo projects in sync.

As a workaround for an IT department that is not competent enough to do the right thing, Bazaar looks to be the easiest to use, most complete solution.

Answer 7

As a last-ditch effort, you can always poke a hole in your corporate firewall with SSH. Look into "ssh tunnels" (and also, come to think of it, "poke a hole in the firewall" might be a good search term too). I think you'll want either the -L or -R ssh option, but I can't recall which or even if they're the right ones for sure. And if you're running windows, it's still possible to use the same exact technique if you install Cygwin first.

EDIT: Sorry I wasn't more clear on how this works. The option you want is -R. It opens a port on the remote machine (for listening). When something connects to that port on the remote machine, the connection travels back down the SSH connection to the local machine, then is fowarded on to the server of your choice in the local network. You could connect to your home computer from your work computer before you leave at night with SSH to open the tunnel. Then when you're working from home, you set your SVN working copy (using svn switch --relocate) to point at your home computer. BTW, the SVN port is 3690 by default, if you're running the svnserve daemon.

Answer 8

Like meador said you could setup SSH tunnels to tunnel through your workstation in the office while you're at home, and gain access to the office SVN.

A great guide for setting up SSH on Windows can be found here: Cygwin SSH for Windows

I did this for a while to get remote desktop access until I was able to setup a proper SSH server with a port open on the firewall.

What you do is from your office workstation, make an SSH connection to your home machine, or optionally a dedicated home server. The parameters for that initial connection would provide a -R (remote) tunnel which is essentially allowing the remote machine to come back through the line on the specified port.

For example, if you issue the following command, all traffic which comes to port 1234 on the server will be forwarded to port 23 on the client. See Remote tunnel.

ssh2 -R 1234:: username@sshserver ^^ from SSH

Then on the home machine, you do something like svn://localhost:1234 and that would gain you access to SVN in the office.

*NOTE: I wouldn't recommend doing this without talking to your admins first, because they can get real touchy when you bypass their security... trust me, i know. ;-)

Answer 9

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 10

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 11

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.

Answer 12

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.