The source code for projects like FreeSWITCH and OpenACD imported into the sipXecs project using git submodules. Using git submodules have the following of advantages
- source code is readily available for developers to work with
- developers can submit fixes to the projects in sipXecs while their patches make their way upstream to FreeSWITCH and OpenACD projects.
- release management have greater flexibility on which patches upstream can be back ported to sipXecs based on relevance to sipXecs
Here are some instructions on how to manage submodules.
Pulling in all fixes from upstream project
If you simply want to pull all of the latest fixes from the original projects upstream, then you add a remote branch to the upstream project, then merge the branch into the git submodule. This uses the standard git practice.
Example: Updating OpenACD:
Step 1. From your source root in the sipXecs source tree, select the proper source branch and run the following:
cd OpenACD git remote add upstream git://github.com/Vagabond/OpenACD.git git fetch git checkout -b upstream upstream/master git checkout master git merge upstream
Step 2. Change read-only git url to read/write. NOTE: For this step you need sipXecs commit rights.
Edit OpenACD/.git/config and change
[remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = git://github.com/dhubler/OpenACD.git
to
[remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = git@github.com:dhubler/OpenACD.git
Step 3. You've updated your local copy, but now you need to commit your changes to sipXecs project. These are the same general steps one would follow for submitting any fix to git submodules. This is a two step process: first pushing the changes to the git submodule itself then updating sipXecs to point to that new revision in the submodule.
git push origin master cd .. git commit -m 'Updated lastest OpenACD' OpenACD
Done. Going forward... you can skip the step git remote add...
and instead of running git checkout -b upstream upstream/master
you can just run git checkout upstream
but the rest of the instructions remain the same.
So what you've done by following these steps is to create a way to track and pull in changes from upstream for a given submodule. The sipXecs project has no idea where these changes come from and it doesn't need to care. As such, multiple developers can perform these steps whenever the need arises.