LiveCode repo name change fixer

[Mark Waddingham]

> 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.

That way round came about because of how we used to managed IDE changes 
- we used SVN behind the scenes and synched changes across. Therefore, 
the IDE submodule was (for a long time) only a mirror of another VCS 
system.

That's obviously not true anymore, which is why your suggested ordering 
might well make more sense :)

> 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.

I don't think I have anything particularly against submodules, as 
greater separation of things should make management of individual 
components easier. The only thing to solve is to make managing the 
submodule pointers easier - that could be resolved using some sort of 
symbolic reference system (which I think is possible via git integration 
scripts and such). Indeed, I think chromium does something along those 
lines to manage all of its third-party dependencies.

It's definitely something we'd like to sort out at some point after some 
planning, after all we don't want to play around with the repo structure 
too frequently... As things always break as a result of doing so, and 
getting back to where you started takes a while.

Mark.

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