How to maintain separate svn repositories for the same project?

Question

I'm using a large (thousands of source files) public project with minor (a dozen source files) local modifications and additions. The local modifications aren't relevant to other users of the big project. The project uses svn, as do we for our own projects. I want to be able to get the updates from the project when it is updated and incorporate our changes; I also want our changes kept under source control.

At present, I'm simply svn updating our working copy of the big project when needed, checking out our changes into a different directory, and copying our changes into the corresponding directories in the big project, with some manual reconciliation of the modifications. It's workable; it's rarely changed, not a big deal, and this way works. But if things on our end or theirs were changing more frequently, it wouldn't be practical. Is there a better way?

Answer 1

You could look into svk for that. It's been a while though, so I can't give you the detailed incantations.

Answer 2

You should consider making a branch for you specific modifications. Here's the chapter on branching out of the svn book.

Answer 3

You really want to use a single repository, branch the existing project to create your version, then use that branch. When the main version changes, you can just merge their updates into your branch (as you'll only get the changes made since last time you merged, its a lot easier that manually merging 2 trees)

If you cannot add your project to the main repo, and have to maintain your own, then svk is something to look into.

Answer 4

Without knowing the details of why you do this, it rather limits potential advice, but I think this is as good as it is going to get for you using SVN. Git is designed to handle this kind of thing, but if you can't add a few files to the larger project, then you certainly can't change the whole source control system.

I would look to add those files to the trunk in a way that everyone else has them but ignores them. For example, you have one property in a file which changes your build script to pick up on these files, and ignores them for everyone else.