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?
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.
1
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.
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.
2