LiveCode repo name change fixer

[Mark Waddingham]

On 2015-09-10 05:31, Monte Goulding wrote:
>> On 10 Sep 2015, at 1:06 pm, Richard Gaskin 
>> <ambassador at fourthworld.com> wrote:
>> 
>> > I also saw the email notice on the fact that we can expect a lot more
>> > submodules in the future to deal with widgets. Not something I'm
>> > looking forward to.

I'm not sure we are looking forward to it either. We're getting to the 
point where we could start to split up various things into separate, 
independently maintainable pieces and as such it would probably make 
sense for them to inhabit their own repository however submodules do 
cause headaches at times for the reason Monte outlines below.

>> What are your concerns?
> 
> The issue with submodules is just a workflow thing. You’ve got to
> remember to commit changes to the submodule before you commit to the
> main repo because the commit on the main repo contains a reference to
> the commit on the submodule. In general submodules that you don’t
> maintain and just update every now and then are a godsend. Submodules
> in the one project that share branch names etc like the ide and
> thirdparty ones in the livecode repo not so much… I’m actually not all
> that sure why these were made submodules in the first place. I’m
> fairly sure we discussed it back when it was all originally pushed but
> it I can’t remember…

I think there are various discussions about it from wayback when.

The prebuilt submodule (now defunct) was to prevent large binary blobs 
that would change periodically taking up repo space (remember that 
github history is perpetual - it monotonically increases in size). 
Eventually my original intention happened with this when we developed 7 
- the submodule got replaced by scripts which downloaded the necessary 
blobs.

The ide submodule was due to the fact we could not use a git work-flow 
in IDE components because of their binary nature. Indeed, for a long 
while, the IDE submodule was a facisimile of an SVN repository which was 
used to do a standard lock-update-unlock flow. Obviously, since then, 
we've get scriptified stacks and a reasonable process of editing the 
binary stacks via using PRs in GitHub so it is much better integrated. 
We periodically have discussions about folding it in to the main repo.

The thirdpary submodule, again, was meant to be a temporary thing - 
again with the point of view of not eternally inflating the size of the 
repository with stuff which is derived or comes from elsewhere. My 
original plan was that all our third-party library uses would be 
downloaded from source, and then patched with our changes at the point 
of build. The only thing stored in the LiveCode repo would then be the 
patches, and not code which is actually maintained elsewhere. 
Unfortunately, however, this is one project which we have never gotten 
around to (but it did come up again recently - so it hasn't been 
forgotten).

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.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps