views:

613

answers:

4

Hi

My company maintains two SVN repositories, Repository 1 and Repository 2:

  1. This repository has multiple projects in it, and is only accessed by the developers within the company. Access is through HTTPS and authentication is through the Windows domain.
  2. This repository has a single project in it, and is accessed by the developers within the company, and our client's developers. Access is through svn:// and authentication is through the passwd file.

We have some code in a folder in Repository 1 that we would like to be downloaded to users of Repository 2. The obvious answer is to use SVN Externals, but as far as I can see, that would need the client's developers to have accounts on our domain, and our IT people don't like that.

Therefore, the only solution I can see is some kind of cron job that runs periodically to copy the necessary files from Repository 1 to 2. I've found a tool called Tailor which claims to do what I need, but so far I've not managed to get it to work correctly.

Before I spend more time trying to get Tailor to work, does anyone have any suggestions of another approach? My last resort is to knock up a program to do it for me, which shouldn't be too hard, but it's always best to use an existing app if there is one!

Thanks in advance for any help/pointers!

Rich

A: 

Do you need to have the external developers change the code in the folder in repository 2, if not you may not need to use SVN at all.

In general, having two repositories with SVN with the same code in is going to be confusing.

Other options

  • If you need the external developers to edit the files in repository 2, could you not have the externals going the other way, so repository1 has an externals definition to repository.
  • Go round your IT people by putting all the code on repository.
  • Use GIT.
Jeremy French
Using externals in the other direction is a clever idea, but we don't actually need access to Repository 2's data, and Repository 1 has all the other project code in it, so I think the other team members wouldn't like that. GIT's not going to happen, sadly, at least not now!
Rich
+2  A: 

If SVN externals would work, but the only stumbling block is access rights, then why not make a clone of the repository and point the externals to that?

SVN now has good support for mirroring:

https://www.opends.org/wiki/page/MirroringASubversionRepository

You can lock down the mirror repository using any authentication scheme you like, for example, anonymous read-only access.

However, you need to ensure that the only thing that updates the mirror is the svn sync command - the users of repository 2 won't be able to commit changes back to repository 1.

This page has some very useful information:

http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt

Jim T
That's a really good idea - the only little niggle, is that the mirror of Repository 1 will have to run on the same machine as Repository 2 - I assume this will mean messing around with ports and so-on...
Rich
If apache is being used for the serving of the mirror, then it's a different protocol/port etc already (this is required for write-through proxy). Otherwise, yes it's a different port, or different IP address (machines can be given multiple IP addresses/names).
Jim T
svnserve --listen-host=otherIP
Jim T
Can changes be commited+propagated to both repositories?
antispam
Rich
If the mirror is served by apache and setup as a write through proxy for the master repository, then yes, changed can be propgated. But I don't know the security model when used this way.
Jim T
A: 

There is SVNReplicate, which maybe could be customized to work with a single project, but this seems a case where a distributed VCS should be more appropiate.

antispam
+1  A: 

I see you need to make changes from both repositories.

You might be able to use the same svnsync idea to build a write-through proxy.

Using this, the mirror repository passes write requests back to the master proxy. Now I'm not sure at this point what happens with authentication, but it's probably worth investigating here.

Might also look at this info.

Jim T