Livecode / Github

Pi Digital sean at pidigital.co.uk
Thu Sep 1 21:40:35 EDT 2022


Thanks Brian for your comprehensive response. What I meant was, though, that ‘ideally’ we need some instructions in the Guide and preferably a GUI for github and the like built into LC specifically for SmartCrumbs. That way the UIDs can be auto converted to the object names and laid out in filestruct format to make sense. Roundtripping to SourceTree or anything else is not really what we want, is it? 

Let me see if I get a chance to knock something up quickly over the weekend. I need to try out these new polylist and polygrid widgets anyway. Linking it to GitHub and remote servers shouldn’t be an issue. I understand how they work so I won’t have a problem. It just needs to be made much much simpler for others. 

Sean Cole
Pi Digital Productions Ltd

eMail Ts & Cs


> On 2 Sep 2022, at 02:26, Brian Milby via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> I think some of this is a bit too much to address in a list post.  I'll
> make some comments though.
> (i) Make a repo at https://github.com;
> https://www.atlassian.com/git/tutorials/setting-up-a-repository; you can
> view tons of docs at https://docs.github.com/en
> (ii)-(iv) I use https://www.sourcetreeapp.com (Mac and Win app available)
> to manage my repos (many other options available). They also have other
> tutorials at https://www.atlassian.com/git
> 
> When you create a GitHub repository currently, it will make a default
> branch called "main".  Initially you would take your stack and commit
> (really another word for "save") to the main branch.  If you had 2
> developers that were working on the same stack at the same time, then one
> way would be to have 2 branches off of main.  Let's say "brian" and "sean"
> for example.  So each of us would check out our branch (initially the same
> as main).  We would make any changes we needed and each would commit to our
> own branch.  When whatever we are working on is ready to incorporate into
> the product, we would merge our branch into the main branch.  Since
> everything is text files (except for the images and other binary resources
> like that), git can detect which pieces have changed and integrate them
> together.  So instead of a zip going back and forth of the full project,
> the individual changes would be tracked and integrated.  The biggest
> difference is that multiple developers can work on the same stack at the
> same time and have their changes integrated together.
> 
> The down side that I do see with this implementation is that it is
> difficult to know what object is being changed.  Since everything is stored
> by GUID it can be hard to know what is being updated by looking at the
> commit logs.  Due to the Mac CR issue, I probably won't be able to do much
> for demonstrating how it works until there is a good workaround (I guess I
> could manually convert the JSON each time for now).  I did fix the JSON
> file on my ScriptTracker repo so it could be viewed on GitHub.  I need to
> make a change to a script that hasn't been fixed to see how it shows up.
> The JSON fix showed pretty much as a whole new file (line 1 was updated to
> lines 1-1000+).
> 
> My approach with ScriptTracker is a bit different.  First is that my tool
> is much more limited (just does the scripts).  But, my tool adds a bit of
> information to the header of each exported script to give it context and
> the scripts are named by the object ID (mainly to avoid issues with illegal
> characters in the object name).  It might be something that could be done
> with plugins to add some info to the JSON and script files.  I'll need to
> take a look - it would make working with the scripts easier.  For the JSON,
> I think it may be helpful to have full object names included with the GUID
> so you have more of an idea what was changed when looking at the diff.
> 
> Also, if you just want to track your changes (and not work with another dev
> to merge), it does get a bit easier.  Then you don't even need to use a
> server (GitHub) but can run git completely on your seat.  The same GUI
> tools mentioned above can be used there as well.
> 
> Command line tools are there but not required.  As I mentioned above, I use
> a GUI for just about all of my git usage.  They make it easy to see what
> happened and when.
> 
> Hopefully this helps a little.  I think there are a couple of videos from
> conferences over the past few years covering Git.  I know that there is at
> least one that I did (but it was targeted at building LC from source).
> 
> Thanks,
> Brian
> 
>> On Thu, Sep 1, 2022 at 5:39 PM Pi Digital via use-livecode <
>> use-livecode at lists.runrev.com> wrote:
>> 
>> Fab :D
>> 
>> however, ‘how’ does one…
>> (i) set up a GitHub (I know how, this is for the benefit of others),
>> (ii) perform commits, push, pulls (perhaps using LC and having an LC
>> library/widget for this would be best),
>> (iii) merge to a branch,
>> (iv) switch branches
>> All the while making it simple for even the most beginner of beginners to
>> understand, like everything else in LC *Should be?
>> 
>> It’s like giving us the front door but the hallway floor is missing.
>> 
>> There is no guide on real world usage so we are left stranded with it.
>> 
>> Here’s the actual situation myself and my colleague face. At the moment
>> one of us works on the app, makes some changes, zips it up, and posts it up
>> to a server. Then the other does the same ad infinitum.
>> 
>> But what you have described is not much different. How can we really tell
>> who made changes unless we know the uid for the script or card (for layout)
>> or object? And are we all supposed to now become command line experts to
>> manage an svc? I’m puzzled at the moment.
>> 
>> It shows great promise, but it’s still not fully ready, is it. It’s
>> usable, like LCB, if you can do lower level stuff. But not many using LC
>> are able, hence why they use LC. Everything LC, and I mean everything, that
>> is front end for LC users *Should, note, Should be High Level and easy to
>> code & understand. The plug-in language for SmartCrumbs is dreamy. Thank
>> you whoever came up with that. I love it! LCB is a nightmare and could have
>> been done so much better - much more in line with the HyperCard principle.
>> 
>> Sean Cole
>> Pi
>> 
>> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


More information about the use-livecode mailing list