encrypting script-only stacks

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

encrypting script-only stacks

Paul Dupuis via use-livecode
Since script-only stacks contain only a script with no properties, they
have no password property, and thus cannot be encrypted.

I had thought that including them in the Stacks pane of the Standalone
Builder might convert them to binary substacks, where the password could
apply.  No dice.

Is it a bug that script-only stacks can't be imported into the stackfile
to become binary substacks?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
Wouldn't a binary script-only stack be the library stack we already have now?
--
Jacqueline Landman Gay | [hidden email]
HyperActive Software | http://www.hyperactivesw.com
On January 14, 2020 9:55:01 AM Richard Gaskin via use-livecode
<[hidden email]> wrote:

> Since script-only stacks contain only a script with no properties, they
> have no password property, and thus cannot be encrypted.
>
> I had thought that including them in the Stacks pane of the Standalone
> Builder might convert them to binary substacks, where the password could
> apply.  No dice.
>
> Is it a bug that script-only stacks can't be imported into the stackfile
> to become binary substacks?
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  ____________________________________________________________________
>  [hidden email]                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode




_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
Sure, and with the extra benefit that you wouldn't have to expose your
code to end-users.

That is, unless there's a way to include SoS in a standalone that
includes encryption, such as an automated method in the Standalone Builder.

I couldn't find one, but it seems like such a pervasive issue for the
class of devs most likely to use SoS (pros dependent on VCS) that I'm
hoping I just missed something.

--
  Richard Gaskin
  Fourth World Systems


Jacque wrote:

 > Wouldn't a binary script-only stack be the library stack we already
 > have now?
 > --
 > Jacqueline Landman Gay | jacque at hyperactivesw.com
 >
 > On January 14, 2020 9:55:01 AM Richard Gaskin wrote:
 >
 >> Since script-only stacks contain only a script with no properties,
 >> they have no password property, and thus cannot be encrypted.
 >>
 >> I had thought that including them in the Stacks pane of the
 >> Standalone Builder might convert them to binary substacks, where
 >> the password could apply.  No dice.
 >>
 >> Is it a bug that script-only stacks can't be imported into the
 >> stackfile to become binary substacks?
 >>
 >> --
 >>  Richard Gaskin
 >>  Fourth World Systems



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
The benefits of SoS are so important that I would hate to have to go back
to binary again. Nothing like having pure text files to version, back up
etc. so I am also hoping for an elegant solution to encode these in
standalone.

On Tue, 14 Jan 2020 at 17:31, Richard Gaskin via use-livecode <
[hidden email]> wrote:

> Sure, and with the extra benefit that you wouldn't have to expose your
> code to end-users.
>
> That is, unless there's a way to include SoS in a standalone that
> includes encryption, such as an automated method in the Standalone Builder.
>
> I couldn't find one, but it seems like such a pervasive issue for the
> class of devs most likely to use SoS (pros dependent on VCS) that I'm
> hoping I just missed something.
>
> --
>   Richard Gaskin
>   Fourth World Systems
>
>
> Jacque wrote:
>
>  > Wouldn't a binary script-only stack be the library stack we already
>  > have now?
>  > --
>  > Jacqueline Landman Gay | jacque at hyperactivesw.com
>  >
>  > On January 14, 2020 9:55:01 AM Richard Gaskin wrote:
>  >
>  >> Since script-only stacks contain only a script with no properties,
>  >> they have no password property, and thus cannot be encrypted.
>  >>
>  >> I had thought that including them in the Stacks pane of the
>  >> Standalone Builder might convert them to binary substacks, where
>  >> the password could apply.  No dice.
>  >>
>  >> Is it a bug that script-only stacks can't be imported into the
>  >> stackfile to become binary substacks?
>  >>
>  >> --
>  >>  Richard Gaskin
>  >>  Fourth World Systems
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


--
Kaveh Bazargan PhD
Director
River Valley Technologies <http://rivervalleytechnologies.com/> • Twitter
<https://twitter.com/kaveh1000> • LinkedIn
<https://www.linkedin.com/in/bazargankaveh/>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
I use Nextcloud with my work folders, so backup with versions is
automatic, and it keeps everything synced across my Mac, Linux, and Win
boxes along with it.

But my needs are modest.  Because I rarely work in teams larger than
three to five developers, and we assign tasks by skill focus so we
rarely need to have two devs working on the same stack file at the same
time, we rarely need automated merge assistance.  In the few cases where
we have needed a merge, a prop diff and tossed-together script-diff have
been sufficient.

I will be using Git more in 2020, though, for open source work, likely
on Github (though I'm still considering Gitlab since it's open source
itself).

Help me motivate to move my Git transition forward sooner:

Beyond backup across versions (since that's widely available in most
cloud storage for even binary files), that Git features do you find most
valuable?

--
  Richard Gaskin
  Fourth World Systems


Kaveh Bazargan wrote:

 > The benefits of SoS are so important that I would hate to have to go
 > back to binary again. Nothing like having pure text files to version,
 > back up etc. so I am also hoping for an elegant solution to encode
 > these in standalone.
 >
 > On Tue, 14 Jan 2020 at 17:31, Richard Gaskin via use-livecode <
 > use-livecode at lists.runrev.com> wrote:
 >
 >> Sure, and with the extra benefit that you wouldn't have to expose
 >> your code to end-users.
 >>
 >> That is, unless there's a way to include SoS in a standalone that
 >> includes encryption, such as an automated method in the Standalone
 >> Builder.
 >>
 >> I couldn't find one, but it seems like such a pervasive issue for the
 >> class of devs most likely to use SoS (pros dependent on VCS) that I'm
 >> hoping I just missed something.
 >>
 >> --
 >>   Richard Gaskin
 >>   Fourth World Systems




_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
My thought was that you'd use the text files during development and then
save them as binary with encryption for the final build.

--
Jacqueline Landman Gay | [hidden email]
HyperActive Software | http://www.hyperactivesw.com
On January 14, 2020 11:38:06 AM Kaveh Bazargan via use-livecode
<[hidden email]> wrote:

> The benefits of SoS are so important that I would hate to have to go back
> to binary again. Nothing like having pure text files to version, back up
> etc. so I am also hoping for an elegant solution to encode these in
> standalone.
>
> On Tue, 14 Jan 2020 at 17:31, Richard Gaskin via use-livecode <
> [hidden email]> wrote:
>
>> Sure, and with the extra benefit that you wouldn't have to expose your
>> code to end-users.
>>
>> That is, unless there's a way to include SoS in a standalone that
>> includes encryption, such as an automated method in the Standalone Builder.
>>
>> I couldn't find one, but it seems like such a pervasive issue for the
>> class of devs most likely to use SoS (pros dependent on VCS) that I'm
>> hoping I just missed something.
>>
>> --
>>   Richard Gaskin
>>   Fourth World Systems
>>
>>
>> Jacque wrote:
>>
>>  > Wouldn't a binary script-only stack be the library stack we already
>>  > have now?
>>  > --
>>  > Jacqueline Landman Gay | jacque at hyperactivesw.com
>>  >
>>  > On January 14, 2020 9:55:01 AM Richard Gaskin wrote:
>>  >
>>  >> Since script-only stacks contain only a script with no properties,
>>  >> they have no password property, and thus cannot be encrypted.
>>  >>
>>  >> I had thought that including them in the Stacks pane of the
>>  >> Standalone Builder might convert them to binary substacks, where
>>  >> the password could apply.  No dice.
>>  >>
>>  >> Is it a bug that script-only stacks can't be imported into the
>>  >> stackfile to become binary substacks?
>>  >>
>>  >> --
>>  >>  Richard Gaskin
>>  >>  Fourth World Systems
>>
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
> --
> Kaveh Bazargan PhD
> Director
> River Valley Technologies <http://rivervalleytechnologies.com/> • Twitter
> <https://twitter.com/kaveh1000> • LinkedIn
> <https://www.linkedin.com/in/bazargankaveh/>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode




_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
That’s a great idea. :-)

On Tue, 14 Jan 2020 at 18:30, J. Landman Gay via use-livecode <
[hidden email]> wrote:

> My thought was that you'd use the text files during development and then
> save them as binary with encryption for the final build.
>
> --
> Jacqueline Landman Gay | [hidden email]
> HyperActive Software | http://www.hyperactivesw.com
> On January 14, 2020 11:38:06 AM Kaveh Bazargan via use-livecode
> <[hidden email]> wrote:
>
> > The benefits of SoS are so important that I would hate to have to go back
> > to binary again. Nothing like having pure text files to version, back up
> > etc. so I am also hoping for an elegant solution to encode these in
> > standalone.
> >
> > On Tue, 14 Jan 2020 at 17:31, Richard Gaskin via use-livecode <
> > [hidden email]> wrote:
> >
> >> Sure, and with the extra benefit that you wouldn't have to expose your
> >> code to end-users.
> >>
> >> That is, unless there's a way to include SoS in a standalone that
> >> includes encryption, such as an automated method in the Standalone
> Builder.
> >>
> >> I couldn't find one, but it seems like such a pervasive issue for the
> >> class of devs most likely to use SoS (pros dependent on VCS) that I'm
> >> hoping I just missed something.
> >>
> >> --
> >>   Richard Gaskin
> >>   Fourth World Systems
> >>
> >>
> >> Jacque wrote:
> >>
> >>  > Wouldn't a binary script-only stack be the library stack we already
> >>  > have now?
> >>  > --
> >>  > Jacqueline Landman Gay | jacque at hyperactivesw.com
> >>  >
> >>  > On January 14, 2020 9:55:01 AM Richard Gaskin wrote:
> >>  >
> >>  >> Since script-only stacks contain only a script with no properties,
> >>  >> they have no password property, and thus cannot be encrypted.
> >>  >>
> >>  >> I had thought that including them in the Stacks pane of the
> >>  >> Standalone Builder might convert them to binary substacks, where
> >>  >> the password could apply.  No dice.
> >>  >>
> >>  >> Is it a bug that script-only stacks can't be imported into the
> >>  >> stackfile to become binary substacks?
> >>  >>
> >>  >> --
> >>  >>  Richard Gaskin
> >>  >>  Fourth World Systems
> >>
> >>
> >>
> >> _______________________________________________
> >> use-livecode mailing list
> >> [hidden email]
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> >
> >
> > --
> > Kaveh Bazargan PhD
> > Director
> > River Valley Technologies <http://rivervalleytechnologies.com/> •
> Twitter
> > <https://twitter.com/kaveh1000> • LinkedIn
> > <https://www.linkedin.com/in/bazargankaveh/>
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
--
Sent from MetroMail
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
Exactly.  I was hoping the Standalone Builder would do that if you
choose to include external SoS in the standalone.

What I found instead is that it doesn't being them into the standalone
stack file as substacks, nor even convert them to binary stack files in
place.  It just refuses to allow a password to be set.

For apps making rich use of SoS, it would seem tedious to do that
conversion by hand, or to expect every developer to write the same pair
of handlers to automate that before and after building the standalone.

How do folks who use SoS frequently protect those SoS scripts?

--
  Richard Gaskin
  Fourth World Systems


J. Landman Gay wrote:

> My thought was that you'd use the text files during development and then
> save them as binary with encryption for the final build.
>
> --
> Jacqueline Landman Gay | jacque at hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On January 14, 2020 11:38:06 AM Kaveh Bazargan via use-livecode
> <use-livecode at lists.runrev.com> wrote:
>
>> The benefits of SoS are so important that I would hate to have to go back
>> to binary again. Nothing like having pure text files to version, back up
>> etc. so I am also hoping for an elegant solution to encode these in
>> standalone.
>>
>> On Tue, 14 Jan 2020 at 17:31, Richard Gaskin via use-livecode <
>> use-livecode at lists.runrev.com> wrote:
>>
>>> Sure, and with the extra benefit that you wouldn't have to expose your
>>> code to end-users.
>>>
>>> That is, unless there's a way to include SoS in a standalone that
>>> includes encryption, such as an automated method in the Standalone Builder.
>>>
>>> I couldn't find one, but it seems like such a pervasive issue for the
>>> class of devs most likely to use SoS (pros dependent on VCS) that I'm
>>> hoping I just missed something.
>>>
>>> --
>>>   Richard Gaskin
>>>   Fourth World Systems


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
On Tue, Jan 14, 2020 at 1:13 PM Richard Gaskin via use-livecode <
[hidden email]> wrote:

> Exactly.  I was hoping the Standalone Builder would do that if you
> choose to include external SoS in the standalone.
>
> What I found instead is that it doesn't being them into the standalone
> stack file as substacks, nor even convert them to binary stack files in
> place.  It just refuses to allow a password to be set.
>
> For apps making rich use of SoS, it would seem tedious to do that
> conversion by hand, or to expect every developer to write the same pair
> of handlers to automate that before and after building the standalone.
>
> How do folks who use SoS frequently protect those SoS scripts?
>

I use SoS extensively but I had never tried using the SB to encrypt them as
I use Levure. The Levure packaging library automatically encrypts script
only stacks for you during the packaging process. While Levure uses the SB
to create the standalone, encrypting the stacks is handled in the Levure
packaging library, not the SB.

I agree that the SB should handle this for you though.

--
Trevor DeVore
ScreenSteps
www.screensteps.com
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
Trevor DeVore wrote:

> On Tue, Jan 14, 2020 at 1:13 PM Richard Gaskin via use-livecode <
> use-livecode at lists.runrev.com> wrote:
>
>> Exactly.  I was hoping the Standalone Builder would do that if you
>> choose to include external SoS in the standalone.
>>
>> What I found instead is that it doesn't being them into the standalone
>> stack file as substacks, nor even convert them to binary stack files in
>> place.  It just refuses to allow a password to be set.
>>
>> For apps making rich use of SoS, it would seem tedious to do that
>> conversion by hand, or to expect every developer to write the same pair
>> of handlers to automate that before and after building the standalone.
>>
>> How do folks who use SoS frequently protect those SoS scripts?
>>
>
> I use SoS extensively but I had never tried using the SB to encrypt them as
> I use Levure. The Levure packaging library automatically encrypts script
> only stacks for you during the packaging process. While Levure uses the SB
> to create the standalone, encrypting the stacks is handled in the Levure
> packaging library, not the SB.

I'm assuming Levure does this by converting a copy of the SoS stack
files to binary stack files, yes?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
On Tue, Jan 14, 2020 at 11:47 AM Richard Gaskin via use-livecode <
[hidden email]> wrote:

> ...
>
> Help me motivate to move my Git transition forward sooner:
>
> Beyond backup across versions (since that's widely available in most
> cloud storage for even binary files), that Git features do you find most
> valuable?
>

Hi Richard -

One way I use Git is to develop multiple features in tandem without
affecting the version I distribute of my app that I distribute to
customers. I love how I can silo my own work on features as well as the
flexibility to see detailed history of changes throughout the life of my
application. I use the Git commit notes and the ease with which you can
review changes in those commits a number of times when trying to track down
at what point a bug was introduced.

Here is an example of how I silo work I'm doing right now. If you looked at
my Git repo earlier today you would see the following branches:

- master
- develop
- tkd-htmltidy
- tkd-remove-answer-types
- tkd-mammoth
- tkd-hires-annotations

`master` always has the release version of the code.

`develop` is code that has been developed, tested, and is ready to go into
the next release. I will create builds from this branch to send to
customers who want early access to a feature or bug fix.

All other branches are features that are being worked on but which are not
finished and require more testing. Some of those branches exist for an
afternoon. Some last for a month or more.

Today I merged in `tkd-htmltidy` and tkd-remove-answer-types` into
`develop` as they were finished and are ready to send to customers who need
early access. When I squashed and merged those branches in there were a
number of changes which had been made in the develop branch since I had
started `tkd-htmltidy`. Those changes were seamless blended together
without any problem, even though there were changes changes made in some of
the same files. In addition, because I squashed the merge, all of the
changes that went into the addition of HTML Tidy are seen as one commit in
my `develop` branch. I made dozens of commits during development but was
able to make one clean commit when I was all done and ready to merge the
changes with the main code branch. This makes for a clean history that is
easier to review later on.

I will continue to work on the tkd-hires-annotations and tkd-mammoth
branches as they aren't done yet and require more revisions. But once they
are ready I perform the same squash and merge. If I want an internal tester
or a customer to test those features out before they are ready I can do
that too. I can use the Git rebase feature to bring in all changes to
`develop` that have been made since I created a particular branch. That
means the tester is using the latest version of the app along with the new
feature I'm working on.

One last example. Let's say that a nasty bug turns up while I'm working on
`develop` and need to get a release out to customers right away. I can go
to master, create a new branch from that code, make the fix, and package up
a new installer. I can merge that fix into `develop` as well so that it
will be included in a future update.

I think the scenarios I describe above are my favorite reasons for using
Git as they make my daily development and management of the code easier.

--
Trevor DeVore
ScreenSteps
www.screensteps.com
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
On Tue, Jan 14, 2020 at 2:35 PM Richard Gaskin via use-livecode <
[hidden email]> wrote:

> Trevor DeVore wrote:
>
> > I use SoS extensively but I had never tried using the SB to encrypt them
> as
> > I use Levure. The Levure packaging library automatically encrypts script
> > only stacks for you during the packaging process. While Levure uses the
> SB
> > to create the standalone, encrypting the stacks is handled in the Levure
> > packaging library, not the SB.
>
> I'm assuming Levure does this by converting a copy of the SoS stack
> files to binary stack files, yes?
>

That is correct. The SoS is opened, the the scriptonly property of the
stack is set to false, and then it is saved using the same filename. This
is all done in a temporary directory so that the source file isn't modified
at all.

--
Trevor DeVore
ScreenSteps
www.screensteps.com
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
Thanks, Trevor.  That's a helpful outline.

I haven't had a business case to support so many branches, but I can see
where it might be useful down the road.

Any opinions on Github vs Gitlab?

--
  Richard Gaskin
  Fourth World Systems


Trevor DeVore wrote:

> On Tue, Jan 14, 2020 at 11:47 AM Richard Gaskin via use-livecode <
> use-livecode at lists.runrev.com> wrote:
>
>> ...
>>
>> Help me motivate to move my Git transition forward sooner:
>>
>> Beyond backup across versions (since that's widely available in most
>> cloud storage for even binary files), that Git features do you find most
>> valuable?
>>
>
> Hi Richard -
>
> One way I use Git is to develop multiple features in tandem without
> affecting the version I distribute of my app that I distribute to
> customers. I love how I can silo my own work on features as well as the
> flexibility to see detailed history of changes throughout the life of my
> application. I use the Git commit notes and the ease with which you can
> review changes in those commits a number of times when trying to track down
> at what point a bug was introduced.
>
> Here is an example of how I silo work I'm doing right now. If you looked at
> my Git repo earlier today you would see the following branches:
>
> - master
> - develop
> - tkd-htmltidy
> - tkd-remove-answer-types
> - tkd-mammoth
> - tkd-hires-annotations
>
> `master` always has the release version of the code.
>
> `develop` is code that has been developed, tested, and is ready to go into
> the next release. I will create builds from this branch to send to
> customers who want early access to a feature or bug fix.
>
> All other branches are features that are being worked on but which are not
> finished and require more testing. Some of those branches exist for an
> afternoon. Some last for a month or more.
>
> Today I merged in `tkd-htmltidy` and tkd-remove-answer-types` into
> `develop` as they were finished and are ready to send to customers who need
> early access. When I squashed and merged those branches in there were a
> number of changes which had been made in the develop branch since I had
> started `tkd-htmltidy`. Those changes were seamless blended together
> without any problem, even though there were changes changes made in some of
> the same files. In addition, because I squashed the merge, all of the
> changes that went into the addition of HTML Tidy are seen as one commit in
> my `develop` branch. I made dozens of commits during development but was
> able to make one clean commit when I was all done and ready to merge the
> changes with the main code branch. This makes for a clean history that is
> easier to review later on.
>
> I will continue to work on the tkd-hires-annotations and tkd-mammoth
> branches as they aren't done yet and require more revisions. But once they
> are ready I perform the same squash and merge. If I want an internal tester
> or a customer to test those features out before they are ready I can do
> that too. I can use the Git rebase feature to bring in all changes to
> `develop` that have been made since I created a particular branch. That
> means the tester is using the latest version of the app along with the new
> feature I'm working on.
>
> One last example. Let's say that a nasty bug turns up while I'm working on
> `develop` and need to get a release out to customers right away. I can go
> to master, create a new branch from that code, make the fix, and package up
> a new installer. I can merge that fix into `develop` as well so that it
> will be included in a future update.
>
> I think the scenarios I describe above are my favorite reasons for using
> Git as they make my daily development and management of the code easier.
>
> --
> Trevor DeVore
> ScreenSteps
> www.screensteps.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
On 1/14/20 7:52 AM, Richard Gaskin via use-livecode wrote:

> Is it a bug that script-only stacks can't be imported into the stackfile
> to become binary substacks?
>

They can, but it's a one-way operation. Once you've done that the
substack and the script-only text file are two different entities.
Editing one won't affect the other.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
On 1/14/20 9:46 AM, Richard Gaskin via use-livecode wrote:

> Beyond backup across versions (since that's widely available in most
> cloud storage for even binary files), that Git features do you find most
> valuable?
>

As in Trevor's description, the advantage of being able to create new
branches for experimental work can't be overstated.

Consider: you have a working project and want to try making some changes
that may or may not work. And that may or may not stop existing things
from working. Or maybe you just want to try some A-B testing and be able
to create two different versions. Or create a new version and be able to
do some performance benchmarking.

All without messing with your existing product code.

If it works you can merge the branch into the main code. If not then
just dump the branch and you haven't lost anything except some time.

I also use tagging in git to set release values, so that I can easily
see what's changed from one release to the next.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
On 1/14/20 2:13 PM, Richard Gaskin via use-livecode wrote:

> Any opinions on Github vs Gitlab?
>

SCaLE is coming up soon. Gitlab always has a table set up.
They're good at answering the hard questions.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
Mark Wieder wrote:

 > On 1/14/20 7:52 AM, Richard Gaskin via use-livecode wrote:
 >
 >> Is it a bug that script-only stacks can't be imported into the
 >> stackfile to become binary substacks?
 >>
 >
 > They can, but it's a one-way operation. Once you've done that the
 > substack and the script-only text file are two different entities.
 > Editing one won't affect the other.

For building standalones that would be fine.  Is that in the Standalone
Builder, or something every one of us needs to write our own script for?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
On Tue, Jan 14, 2020 at 4:14 PM Richard Gaskin via use-livecode <
[hidden email]> wrote:

> Thanks, Trevor.  That's a helpful outline.
>
> I haven't had a business case to support so many branches, but I can see
> where it might be useful down the road.
>
> Any opinions on Github vs Gitlab?
>

I've only used Github so I can't offer up a comparison. I've been happy
with Github for the most part and my company has been working with it for a
number of years.

--
Trevor DeVore
ScreenSteps
www.screensteps.com
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
On Tue, Jan 14, 2020 at 10:36 PM Mark Wieder via use-livecode <
[hidden email]> wrote:

> On 1/14/20 9:46 AM, Richard Gaskin via use-livecode wrote:
>
> > Beyond backup across versions (since that's widely available in most
> > cloud storage for even binary files), that Git features do you find most
> > valuable?
> >
>
> As in Trevor's description, the advantage of being able to create new
> branches for experimental work can't be overstated.
>
> Consider: you have a working project and want to try making some changes
> that may or may not work. And that may or may not stop existing things
> from working. Or maybe you just want to try some A-B testing and be able
> to create two different versions. Or create a new version and be able to
> do some performance benchmarking.
>
> All without messing with your existing product code.
>
> If it works you can merge the branch into the main code. If not then
> just dump the branch and you haven't lost anything except some time.
>
> I also use tagging in git to set release values, so that I can easily
> see what's changed from one release to the next.
>

I'll toss in an amen to both of these points (testing optimizations, etc.
and tagging releases). I use Tower as my Git GUI with Kaleidoscope for
diffs. I can easily see a diff of all files that have changed between two
releases because I tag the commit that was current at release time of each
version.

--
Trevor DeVore
ScreenSteps
www.screensteps.com
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: encrypting script-only stacks

Paul Dupuis via use-livecode
In reply to this post by Paul Dupuis via use-livecode
I REALLY need to start using GIT. I am running into that constantly. Are database schema changes gitable, or would I need to create a separate schema?

Bob S


> On Jan 14, 2020, at 20:36 , Mark Wieder via use-livecode <[hidden email]> wrote:
>
> On 1/14/20 9:46 AM, Richard Gaskin via use-livecode wrote:
>
>> Beyond backup across versions (since that's widely available in most cloud storage for even binary files), that Git features do you find most valuable?
>
> As in Trevor's description, the advantage of being able to create new branches for experimental work can't be overstated.
>
> Consider: you have a working project and want to try making some changes that may or may not work. And that may or may not stop existing things from working. Or maybe you just want to try some A-B testing and be able to create two different versions. Or create a new version and be able to do some performance benchmarking.
>
> All without messing with your existing product code.
>
> If it works you can merge the branch into the main code. If not then just dump the branch and you haven't lost anything except some time.
>
> I also use tagging in git to set release values, so that I can easily see what's changed from one release to the next.
>
> --
> Mark Wieder
> [hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12