Support external Subversion repositories

From David Soul:

A customer has emailed us to say that they're interested in having hosted Studio connect to respositories that are hosted in-house. Kevin Pierce (kpierce@vendasta.com) says:

> The only tool we forsee truely needing to handled ourselves inhouse is
> svn, since we use this heavily for all types of activity and require
> real network connectivity.

Just for your consideration.

Customer comment:

Gus Heck - 18/Mar/08 05:48 PM
Not having admin access to one's repository gives me the willies. If anything gets messed up (such as accidental check in of sensitive information that must be removed) the inability to shut down access, dump/filter/etc is a serious problem (and yes I've had to do that ). However, if one could connect your services with a repository that I can manage freely. Also, having my code live elsewhere and only being able to get a backup via a service ticket is an issue. Are you prepared for users that file weekly tickets for backups? And the faq seems to indicate that none of the backups you do can be re-loaded, so if something goes wrong the only option is to quit using Jira studio to fix the problem? what is the use of a backup that can't be loaded?

Don't get me wrong, I love the idea that I one could potentially get going on Jira/confluece/fisheye/crucible for only $50/month. That's an awesome concept, but having to put my subversion there is something I view as an additional cost. What would be a benefit would be a service to automatically replicate or back up my subversion repository. Perhaps you could have a mode where a regular polling for new versions on an external server is done and then when new versions are detected, a robot client updates to each version successively and checks in the changes to the repository at Atlassian one by one.

In pseudo code:

while(accountIsPaidUp())
if(newVersionsFound())
foreach(getNewVersionList() as v )
updateCheckoutSpaceToVersion(v)
copyNonSubversionFilesToCheckinSpace()
Options opts = determineCheckInOptions() // this is possibly difficult
commitCheckinSpace(options)

That would allow you to have all the integration with your tools operating locally. There's probably a bit more with some of the other funky bits of subversion like locks, but I'll leave that as an exercise for the folks who're getting paid for this Anyway, just a thought for you because I definately like where you are going, but I'm not sure I could follow yet.

I would expect that an account set up to use external repositories would NOT be allowed to make any changes to the atlassian copy of the repository directly (only via the mirroring process).