views:

47

answers:

3

I'm working with a 3rd party API that is distributed as source code. This is great because I can fix things on my own, but I also receive lots of updates from the 3rd party.

I have my own svn repository for my code base that includes my version of the API. I get the official API updates by checking out a version from the 3rd party's svn repository.

Merging the changes is a painful process. Is there a better way to do this? Would this be easier with a distributed source control system?

+3  A: 

The problem is that you're coupling yourself to the API. Find a way to extend the API rather than modify it, if you can. Put it in a separate module or other compilation output (i.e. .JAR, .DLL, .SO file). Try to decouple yourself from it.

If you can't do that, you're pretty much stuck dealing with a merge every release.

Of course, if the API is open source, you might consider submitting your changes...

Randolpho
+1  A: 

I don't think distributed version control systems will help much in your scenario as it seems you'll be the one doing the merging to your own repository. If the nature of the merge is the API and the code that depends on that API, nothing can help you much.

Mehrdad Afshari
+1  A: 

Abstract the API from your code. There are many design patterns you can use (facade, proxy, etc) that will help you keep your code insulated from changes in the API. If the API changes, change the code that interacts with it instead of the API itself. You'll still need to make changes to your code every time they update their code, but at least it will be minimal and isolated to one place.

Todd R