6

What is the best way to keep third-party source code up to date?

For instance in my app, I'm using third-party source code from an open GitHub repository. What I've done is that I have downloaded the zip of the source code, unpacked it and imported it in my iOS app and then started modifying this source code to my hearts content.

So this third-party source code has been working great for me, but now some months later the developer of the third-party source code released an update to his code from 1.0 -> 2.0. Now of course I want to have this update as well in my iOS app. What would be the easiest way to migrate my 1.0 third-party source code (together with all my additions to the code) to 2.0?

  • 1
    Why didn't you use git so that you could merge branches? Also, why didn't you re-commit the new features you made back to the project already? (I'm assuming it's open source and that your changes could have helped more than just you) – Ampt Jul 17 '13 at 21:26
  • Are you open to forking the original code you downloaded on github? – user40980 Jul 17 '13 at 21:47
  • @MichaelT I'm not that familiar with git lingo... With forking you mean install it as a git repo locally on my computer? – Peter Warbo Jul 17 '13 at 21:52
  • Also the modifications I'm making are only to tailor it to my app. It's not really of any value to the rest of the community... – Peter Warbo Jul 17 '13 at 22:04
  • If you modified the original source files instead of extending the functionality you made a mistake. Now it will be much harder to merge the original source updates into your changes. Now your options are limited, basically your only option, go line by line and merge the changes by hand. – Ramhound Jul 18 '13 at 14:03
5

While you are using any code repository from github there is possibility of you 'forking' it. By forking it means that you can make your version of the repository. Then if you make changes(e.g. bug fixes) then you can send the original creator a 'merge` request. If the original creator accepts your changes will also be made into his repository.

In case your changes aren't something that original creator would accept then you can maintain your app in modular form. Try not to change the original interface of the 3rd party lib. That should make it possible for an update to take place.

If that isn't possible either than you can use diff to find the difference between the 2 versions and then manually make the changes. You can also find the difference by 'cloning' the git repo on your computer. Then going through the commits you can figure out the difference. That would be a longer path. I'd suggest using diff to find the difference between the 2 versions.

As MichaelT has pointed out diff3 can be more suitable for such a comparison.

  • There is also diff3 which is used for merges - comparing a common ancestor and two branches of it. – user40980 Jul 17 '13 at 23:00
4

In getting a copy of the code and making local changes to it, you have effectively branched it. Meanwhile, back on the main line other changes have taken place and a 2.0 version has been released.

enter image description here

Note that these #1, #2, #3 do not need to match up, nor are they the same feature - just a representation of several changes that have been made to each codeline.

This is what it looks like now, and you are trying to make that merged 2.0 point.

Just doing a diff of the code at Your change #3 and version 2.0 will show you what has changed between the two, but it doesn't show how that fits in. Unless you have marked your code somehow, you will have difficulty determining if the difference between your change #3 and version 2.0 is changes that new features in the mainline, or changes you did in your branch.

For this, you need to use diff3 that that implements a three way merge of the your code, the oldest code, and their code. This takes the version 1.0 as a change.

The man pages for diff3 on developer.apple.com and opendiff on developer.apple.com (you can also use FileMerge on the mac - remember to expand the window for the 3 way diff. See also How do you do a 3-way merge in FileMerge? - you may also find p4merge from perforce to be to your liking).

Merging an entire major upgrade may be a significant undertaking. I can't say how much has changed in the mainline between version 1.0 and version 2.0. Long term, you should consider using git, forking the repo and then consistently doing pulls of changes into your branch. This is covered under pull in upstream changes in the git fork a repo article. Doing this for smaller changes will help you keep your code up to date and also reduce the workload compared to major changes. It will also keep you up to date if there are major sections being reworked that you have changes in so that you are aware you will need to budget time there to reintroduce your changes.

  • 1
    Thanks for your thorough answer. I'm looking for the long term strategy which you pointed out in the end of your answer. So the strategy is always to fork the repo when possible? As you understand I'm also version controlling my own code using Git (but it's hosted on Bitbucket). What would be the best way to have this forked repo included (version controlled) together with my own code? Should I use git submodules for this? – Peter Warbo Jul 18 '13 at 7:10
  • @MichaelT - Yeah, I'd also like to know what the best practice is for using this forked repo as part of your own code. For example, if you had an iOS project that uses an image picker library. You create a fork of the image picker library, make any modifications, and then how do you get this to be used in your project now? I'm leaning towards git submodules for this... – Tony Aug 20 '13 at 21:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.