views:

215

answers:

4

I have checked out an external svn repository that I have applied a couple of patches to.
(Applying the patches can only be done manually due to conflicts.)

Now I want to be able to maintain this local copy of the remote repository in a proper way.
(I do not have any other access rights than read on the remote repository.)

First of all I need to be able to check-in my local changes in some sort of source control system since there were manual steps involved in applying the patches.

And secondly I still want to be able to receive updates from the remote repository.

What is the best way to achieve this?

+1  A: 

I guess I could use a different source control system for my local copy than svn?
E.g. checking in my complete local copy including the .svn folders into cvs.

Or I could also use git-svn but I’m not sure if that is the best solution.

Any better suggestions?

Update: Yes, git-svn seems to be the preferred solution.

But for the record, one could also use hg with svn.

Ola Herrdahl
git-svn would be a fairly good solution, actually. The main issue here is that svn is not designed to have "local repositories" - normally what you're doing would have been done in a branch if done in svn.
Amber
+1 for git-svn, it's the best way of managing this kind of case.
Jim T
A: 

I understand SVK can do this in a purely Subversion environment (I used it for something like this a few years ago). However, if you're keen to try out Git, then git-svn may be an even better choice. That's what I would use today.

One caveat, though - if you're using Windows then there may be problems getting git-svn to work. I've had limited success in that area and don't use git-svn on Windows because of that.

Greg Hewgill
A: 

With svnsync you can keep a copy of a svn repository, but from the moment you modify your local copy you cannot continue syncronizing.

I would suggest to use git for your final day-to-day work. Keep a local working copy of the svn repository and put it under git control. That will be git master. Clone that repository in a different location, branch master and work there, applying your patches directly to the branch.

Regularly update your svn wc and pull it into your git repository, as master. Then, merge master with your branch.

The confusing thing is that you will have "two git users", one will be the local svn repo working copy and the other your patched branch.

schastar
+1  A: 

A traditional way of doing this is to take an exported version of the code and check it in into your own repository. If there's updates on the code, you merge them into your repo. You can help merging by clever branching (lookup vendor branches). Tag the code in your repo according to the versions of the exported code you checked in.

sbi
I think you are right on. It is a simple issue of managing multiple branches, and doesn't need to be made more complicated by the specifics of which tools to use. It should be possible to accomplish in most modern day version control systems. I had a very similar issue, to which I received some great responses: http://stackoverflow.com/questions/1683096/subversion-merging-a-vendors-source-code-releases-into-mainline-at-regular-inte
RjOllos