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. _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
