LiveCode Forums.

Here's a potential workflow issue for external contributors with the current use of submodules (and the way git submodules work in general)...

If I've forked the main livecode repository in GitHub then my fork points to the original runrev submodule repos. If I want to change something in a submodule I should presumably fork that too but then I need to update my fork of livecode to point at my fork of the submodule - this is a change which will show up in all of my pull requests if I push it back to my livecode fork. If I don't push it back I'll have pull/merge issues forever.

If I've got forks of all the submodules I'll need to keep them synced independently of the main one all the time...

I'm guessing the answer is we really shouldn't need to fork/modify the submodules much/at all. Or maybe some handy scripts could be developed to manage the process cleanly?

Any thoughts?

The general aim is that the submodules shouldn't need to be changed very much at all - as I mentioned on another thread they are very much 'supporting' and will (in time) be replaced with better systems for managing their purpose.

In the meantime though, yes, I'm intending to put together some simple scripts to manage them more easily.

For now, just remember that when you checkout a branch (such as release-6.0.1) you need to do the same on all the submodules.

Yeah.. I've got a tendency to think the IDE submodule is going to be problematic because it will be changing so much.. even if it were text based it would still be an issue... on the other hand if you mix it with the engine repo then the engine developers will need to wait while IDE developers sort out the merge mess that is surely to follow a merge on the IDE repo..

My gut feeling is get the IDE out of there entirely so we can all just put our IDE forks and our engine forks next to each other. Not sure if you can do the same with the other repos but there seems to be lots of stuff lumped together that could be separated into individual repos. Externals could be individual repos for example all including libexternal as a submodule. It would probably be more logical for them all to have their own development cycles anyway...

Well the IDE problem is one that is yet to be solved - at the moment we can't accept pull requests for IDE changes since we don't have VCS; thus the ide folder is basically just a snapshot of what we currently hold in our internal SVN server.

In regards to individual repos for externals and different dev cycles - I'm not sure this is really the right way to go. The core of LiveCode currently consists of IDE + Engine + Docs + Externals, all these things are developed in dev-cycles so there is a single periodic point which is ascribed a particular version. For that version, people can be sure what they are getting and what features and bugfixes there are; having different dev-cycles for these things would be a complete nightmare.

Now, in the future, as the core reduces in size and becomes more modular we will have to rethink how this works - but for now, I do think a single self-contained repository makes the most sense.