[reSIProcate] replacing contrib folder with git submodules

[Daniel Pocock]

On 30/03/2020 19:44, Scott Godin wrote:
> I am personally not a big fan of git submodules.  They are very
> confusing to grasp, especially for those coming from an SVN world. My
> ignorance aside..  :)  
> 
> I'm not sure what value we will get for all but a couple of our contrib
> items.  It seems this would likely be very disruptive for our Windows
> community (unless there are solutions to the customization's outlined
> below).  Some quick notes on each contrib item:
> 
>   * ASIO (include files only item) - we have no custom modifications
>     here, this contrib item is a reasonable candidate to be a GIT submodule
>   * CAJUN (include files only item) - I believe we don't have any custom
>     modifications here, this contrib item is a reasonable candidate to
>     be a GIT submodule
>   * cppunit - we maintain our own custom Visual studio project files for
>     our supported VS versions in these folders
>   * db - we maintain our own custom Visual studio project files for our
>     supported VS versions in these folders
>   * GeoIP  - we maintain our own custom Visual studio project files for
>     our supported VS versions in these folders
>   * getopt - this is only one source file and one header file - likely
>     not a candidate for a submodule
>   * MySQLConnectorC - for windows builds only
>   * Netxx-0.3.2  - we maintain our own custom Visual studio project
>     files for our supported VS versions in these folders
>   * opensigcomp - don't think this exists anywhere else
>   * pcre  - we maintain our own custom Visual studio project files for
>     our supported VS versions in these folders
>   * popt  - we maintain our own custom Visual studio project files for
>     our supported VS versions in these folders, we have some minor fixes
>     for 64bit compiler warnings as well
>   * srtp  - we maintain our own custom Visual studio project files for
>     our supported VS versions in these folders 


There is a strategy to deal with that:

- we make a fork of each of those projects that we need to modify, e.g.
at https://github.com/resiprocate/asio

- in each of those forks, we make a branch to carry all of our
modifications.  The master branch remains pure.

- we pull changes from upstream into the fork from time to time and
merge them into our branch

- we can submit pull requests from our forks to the upstreams, maybe
they will merge and support some of the things we changed

- our submodules config file links to our forks, not directly to the
upstreams

I don't see this as an essential or urgent change to the way we work but
I felt it was a good idea to write it down.  It offers some benefits,
for example, because we can see the difference between our forks and the
upstreams more clearly.

Regards,

Daniel