Editing Large Scripts is Faster

[Richard Gaskin]

Ali Lloyd wrote:

> On Sat, Sep 5, 2015 at 12:02 AM Richard Gaskin wrote:
>
>>  Let's not let Github's limitation impede meaningful work.
>>
>>  What we need is a way to ensure that the changes applied are
>>  the changes we want.
>>
>>  Format is a distant second to that, merely a means to that end and
>>  something we can overcome.
>>
>>  Let's brainstorm ways to fix this critical problem holding up so
>>  much of the work we could be sharing.
...
> Yes, I completely agree that this is a problem which needs a
> solution. But the fact remains that we currently don't have one.

Au contraire, mon ami:  We're surrounded by possible solutions, we just 
haven't picked one yet.

I agree that solutions favoring Github should continue to be preferred 
wherever practical.

But Github is only a means to a goal, and of course not the goal itself. 
  Where it helps achieve a goal that benefits LiveCode it should be 
used, and where it may impeded a goal that would benefit LiveCode other 
options will be needed, perhaps crafted in LiveCode itself (it's a 
wonderfully flexible and efficient language). Software was produced long 
before Github was born, and will continue to be produced long after 
Github is replaced, so we have a long history of productive options to 
inspire us as we work our way toward a solution.

Thankfully most of what we need is already handled well with the current 
Github setup, including not only the engine but also docs and nearly all 
libraries.

But from time to time we may have an edge-case opportunity for a 
component in LiveCode's native file format, such as the one on our 
plates now.  For those we'll want to be able to act on community 
contributions where they help add value to the LiveCode experience.

It may be helpful to separate what we *want* from what we truly *need*.

Clearly what we *want* is a Github-savvy solution, but Github was never 
designed for how LiveCode works so there are edge cases like this one 
where that one option isn't practical.

What we *need* is the ability to:

- IDENTIFY specific changes between a master stack file
   and a modified one.

- REVIEW those changes to ensure fitness, compatibility,
   and security.

- MERGE those changes into the master, if for some reason the
   master has been altered since the changes were submitted. (if
   the master hasn't changed of course the new stack file can
   simply become the master going forward).

There are specifics of each step we could explore in more detail, but 
it's worth noting here that it seems from your post that the v7 IDE is 
effectively frozen in terms of LiveCode Ltd's changes, with the team's 
efforts going into the dev branch for v8, and dependent on components 
that require v8's Builder language and thus preclude traditional 
backporting.

That the v7 IDE has few if any changes between minor release means that 
a merge per se may not be needed.  And since an object merge is the only 
complex step not already addressed through relatively simple tools, we 
have hope for a workflow that may allow the community to continue to 
advance the IDE shipping with the current product while the team focuses 
on the future.

I'll follow up offline to explore these details with you in our next 
Community meeting, and look forward to reporting back here either a new 
workflow for these rare edge cases or a solid understanding of why the 
current IDE cannot be enhanced.

--
  Richard Gaskin
  LiveCode Community Manager
  richard at livecode.org