Keeping code in multiple SVN servers

Question

As a freelance developer, I like to keep all my development in my own SVN server both for continuous integration as well as book-keeping as to what changes were made and when.

I am now working with a client who also uses SVN internally and would obviously like me to work with their development team on their SVN server.

This is great in general, but it would also cause me to abandon my working practices on this project and lose my internal book-keeping method. If this happens alot, then I'll end up with pretty loose working standards - ultimately varying by the project (which I obviously don't want).

Is there some creative way to get the best of both worlds, and have the code exist on commit in both SVN servers? I don't mind a little extra work either up front or on each commit/update to pull it off.

svnsync looks like maybe a good option. Has anyone tried this? Does anyone have other suggestions?

Answer 1

I am not sure what the problem is. You use a different SVN URL, but everything else is the same. What do you mean by "book-keeping"?

Perhaps it boils down to who owns the code - if it is them, they have every right to ask you to use their version control system. And, since it sounds like you are working with a development team, they have you outnumbered.

Because there are other developers involved, you obviously must work off their repository to make sure you always have the latest code and thus avoid conflicts, etc.

If you are concerned about keeping a copy of the code (assuming that is legal), there are many ways to achieve that, e.g., periodically export the working folder pointing to their server to another working folder on your machine pointing to your server, and commit.

Answer 2

You could periodically (weekly?) svndump your clients repository and import that into your own server so you can perform your analysis for billing purposes or other.

The only problem I can think of then is how happy your client might be for you to do this.

Answer 3

Surely the version control system aids in the sharing and management of code. If you are using two repositories things are going to get very messy, very quickly. I'd go with the flow and use whatever the company asks you too

Answer 4

I can see two different approaches here, either you continue working in your repository and then manually do drops to their repository when you feel your code is up to par. The other approach would be to look into svn commit hooks - i.e scripts that run whenever a commit is done. From such a script I presume that you could easily make the same commit to another repository.

I assume that your contract allows you to keep the code for yourself as well, otherwise you pretty much have to do whatever your client tells you with the code.

Answer 5

If you're only interested to list the changes you made in Subversion (I guess, # of commits per week, list of the issues fixed...), you could write a simple Java application that queries any Subversion repository for your changes. After that, it's just a question of pointing your application to the right repository.

There are a couple of easy to use Subversion libraries and I had no particular problem with SvnKit.

Answer 6

Using the client's repository

One solution would be to just use your client's repository directly. Any other "stuff" that doesn't belong there, that is relevant to your book-keeping only, such as your project management, timekeeping, etc, could go in your local repository. You'd keep the two separate, with two separate working copies, although you could set up an svn:external in your local repository pointing to the client's repository if you want to get a little tricky.

That should work as long as both you and the client are happy with how fine-grained your commits are. You can also consider working in a branch in your client's repository, and merging to the trunk when you're happy with your work. It also has the advantage (for your client) that the client has a back-up of all your work-in-progress, which they may like.

git with Subversion integration

Another solution could be to use git locally, and make use of its ability to work with Subversion. You could keep your work-in-progress in a lightweight local branch.