On 2015-09-10 05:31, Monte Goulding wrote:
On 10 Sep 2015, at 1:06 pm, Richard Gaskin
<ambassa...@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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
