LiveCode repo name change fixer

Monte Goulding monte at sweattechnologies.com
Thu Sep 10 06:37:26 EDT 2015


Thanks for explaining all that again Mark. It does sound vaguely familiar.
> 
> One option, in the future, if we move to a multi-submodule arrangement is to make it flat and not a tree - which I think is the main problem (if you mutate a leaf, you have to then change all ancestors of said leaf). Instead, we'll have a core repository which points to a list of all projects (as which are needed to build the product. We can use scripts to make the links at the top-level symbolic rather than hash based which would solve the having to update the parent problem. If this is then combined with a 'thirdparty libraries is download link + patch' type arrangement it should mean that all projects are leaves and don't require nested submodules. However, this is probably a way off, a fair bit more thought needs to go into it as we divide things up into separate extensions.

Hmm… I’ve wondered if one of the issues is the fact that the ide and engine repos are back to front in terms of the normal way you would use submodules. As the IDE depends on the engine and not the other way around it seems more logical to put it in a root repo and then have the engine be a submodule. That way there’s no issues like the engine guys checking out the most recent IDE to see if the engine fixed or broke something and that checkout dirtying the engine repo.

Personally I’d rather see more use of submodules and more hierarchy rather than less. Each thirdparty thing could be a submodule if there’s a public git repo for them so they can be updated easily.


More information about the use-livecode mailing list