Synchronize SVN through FTP

Question

Hello. My team is working with a group at another company with pretty stringent IT policies. We are not allowed any direct access to their SVN server. They are not allowed to access our SVN server. The only option we've been given is access to a shared FTP server. So, I'm looking for suggestions for keeping our repositories in synch. Note that this FTP server is the only communication mechanism other than email so svn:externals are not an option.

My current thought is a nightly (or as often as needed) diff/patch going in both directions. For what it's worth we're each working of pretty independent components so the chances of conflicts is pretty low.

Any better ideas?

Edit: I realize that I should "fight the man" a bit on this, but it has been weeks and the FTP (presumably SFTP) is not even in place yet. Thus I'm looking for clever solutions. The nature of our industry and the system we're working on precludes 3rd party storage of the code. Yes, this is silly and bureaucratic. Way it goes :)

Answer 1

You could use git-svn on both sides and synchronize/exchange your Git repositories using the FTP connection.

Answer 2

Why are you allowed an FTP server and no HTTP or SSH access?

If you're concerned about security, plain FTP certainly isn't providing it, and SFTP requires SSH anyway, so you could use SSH/SCP to synchronize with repositories (this works much better with Git than SVN, as most version control tasks do).

SVN can be utilized over HTTP without much fuss -- why not just run a nightly checkout and throw it up on an HTTP server that everyone can access, take their patches there, and only merge into the general working SVN repository when you like the patches you get?

And, not to beat a dead horse, but Git is more than worth the investment it takes to switch. Please consider switching.

Basically, that setup is non-sensical, and you should stand up to the thoughtless bureaucrats who've implemented it and try and find a workable solution where you can share at least somewhat directly some version control mechanisms, even if they're not first-level repositories that your groups use as their primary source control systems.

Answer 3

I'd suggest some push back. The good thing about stringent IT policies is that usually this means there is an established process for updating the policies. Determining the process can be challenging, especially if you're also "playing telephone" (ie. you can't talk directly to the other folks).

Beyond any doubt source control is a best practice. The policy of disallowing access to a common source control repository is not a best practice. A neutral 3rd party that only provides source control might be the best solution (lots of hits for "svn hosting"). You could probably even arrange for svn hosting on port 80 (or 443) via Apache... so no firewall adjustments would be required.

I'd also suggest to the PM to add X minutes per task due to the overhead of not having shared source repositories (maybe even add a weekly "fix the source repository task" for a couple of hours). I'd certainly consider spend some time and effort in tracking the effort involved in the process (if the process only eats 1 hour a week that's still an important amount of time to track).

Also... just curious... will you be running a continuous integration server with this scheme? Maybe I'm being pessimistic but I'd expect lots of broken builds because of merge problems... and pretty much each time it will look like the opposite's party fault. I wonder if this scheme precludes CI (yet another best practice)?

Answer 4

If you're restricted to FTP, I second your current thought. FTP is not a "live" transfer protocol; you'll need a watcher on the either end to notice a change in the drop folder regardless of the files transferred.

If your paying client has set out terms of engagement that require a little creativity, then so be it. Use svn diff, patch, some cron scripts, and plenty of e-mail notifications in case of error.

Anyone who has worked with government and large corporate entities in the past will sympathize with your position. In fact, there are a lot of Fortune 100 companies out there that use the "drop box pattern" for good reason... it does create a level of indirection against attack that is useful for highly-targettable or large-volume sites. Annoying, yes, but until you walk a mile in their shoes is it really worth pushing back? After all, the developers on the other end are probably as displeased about the restrictions as you are, but everyone wants to get past those and deliver working code as best they can.

Make recommendations on alternative technologies for "future projects... at the appropriate juncture", but meet the restrictions and requirements of the current project head on. Once you've established credibility with your client, it's easier to make recommendations that will be adopted.

For now, write the best and most robust FTP-based SVN merge script you can... it'll be fun!

EDIT: It seems you're not alone. I've never used this project, so I can't credit it, but the description at least acknowledges your issue: svn2web. "Subversion pre- or post-commit hook that can be used to copy committed files either on the same or a different server, via sftp or ftp."

Answer 5

It seems strange that they wouldn't be able to create a branch for you and give you access to that. That way, if there are any issues, they simply don't need to merge your branch.

Answer 6

I was in a similar situation, and we ended up using bazaar instead of subversion because it supported being able to read/write remote repositories using nothing but FTP or SFTP (no need for a client program on the other end).

You didn't mention your OS, but if you're using windows, bazaar comes with TortoiseBzr which will be familiar if you use TortoiseSVN already.