gitter

[Monte Goulding]

> On 31 Jul 2017, at 6:59 am, Mark Wieder via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
>> 
>> Actually, submodules actually do their job really quite well. They aren't ideal, but they do enforce modularity (hence the name ;)). We just need to get round to sorting out some tooling (local shell scripts / git hooks) to help make sure they aren't quite so easy to forget about syncing properly.
> 
> It's possible (and IMO preferable) to have a modular approach to app building in makefiles and such without forcing git to have to deal with that.

Submodules are very helpful when they are doing what they are meant to do which is point to a specific version of a dependency.

Unfortunately with the ide submodule we have two way dependencies and tests that break in one or the other or both if they aren’t updated in sync. Indeed we have some ide libraries in the engine repository. So sometimes to make a seemingly small patch you need to patch both repos. Additionally it’s easy to break an IDE test and not find out about it until everything is merged up because tests are run against the main repo (this is potentially solvable by working out how to run the tests for all the submodules but it will require some special Travis wrangling). 

There is an overhead to all this that I personally believe doesn’t justify the benefits. Should we have IDE A/B test versions then I think we will need to branch the engine repo for them sometimes anyway so any benefits may be less than they at first appear… indeed the scenario may multiply the overheads… 

Anyway, probably better to continue this discussion internally as not may people here would be interested in this.

Cheers

Monte