On Feb 26, 2009 at 04:50, Juha Heinanen jh@tutpro.com wrote:
Jan Janak writes:
- we use 3 repositories: sip-router - like now, only the common part: core, tm and common modules ser-ng - sip-router + ser modules kamailio-ng - sip-router + k modules
why can't ser-ng and kamailio-ng contain just the modules so that sip-router would be only on place?
Because it would be quite hard to do development on modules. To test one module you'll need the core. If you bring the core (merge the core over the modules or the modules over the core), when you'll try to push the change it will bring everything with it (if you're trying to push to ser-ng-modules for example it will push also the core or if you're pushing to sip-router it will add also the modules). So you'll have to take all the changes you did while testing the complete stuff as patches and apply them on a clean local clone of the modules repo. There are some variations possible like using git cherry-pick (depending on how you do the sip-router - modules merge), but in essence is not significant less work then applying patches (via git: git format-patch to create them, git am to apply).
Basically the problem is that you cannot push only the changes made to a subdirectory (you cannot do git push modules/*), you always push the changes to the entire project. We cannot use other workarounds (like git submodule), because of our directory structure (git submodule will work only if a subproject is contained in a subdirectory of another, which is not true in our case: sip-router contains core + modules/tm +modules/db_*, while the other repos will contain modules/*). The only alternative I can think off is to re-organize the modules: have a modules directory containing only the common part (tm and db_* for now), a kmodules containing kamailio modules and smodules ser modules (this way we can have kmodules and smodules as git submodules).
Andrei