[reSIProcate] replacing contrib folder with git submodules

[Scott Godin]

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

Scott

On Sun, Mar 29, 2020 at 11:13 AM Daniel Pocock <daniel at pocock.pro> wrote:

>
>
> Hi all,
>
> Git offers a feature called submodules that allows us to pull other
> repositories into our own.  You can think of them like pointers or
> symlinks.
>
> It is an alternative to keeping full copies of things in the contrib/
> folder and releasing a contrib tarball.
>
> It is not completely identical though:
>
> - if the upstream projects release tarballs based only on their Git
> tags, the contents of a submodule are identical
>
> - if the upstream projects use 'make dist' or a similar mechanism to
> create tarballs, their release tool puts extra things in their tarball
> that are /not/ in their tag.  In this case, a snapshot of their tarball
> in the contrib/ folder remains the better solution.  Example: our tags
> contain resiprocate.spec.in and our release tarballs contain an extra
> file, resiprocate.spec, generated from the .in file.
>
> Using submodules reduces the size of the repository
>
> It is valid with any Git service, not only Github
>
> Regards,
>
> Daniel
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20200330/342e7176/attachment.htm>