I would agree that a LC specific (smartcrumbs specific actually) interface
to git would be helpful. On the back end, it would just be native git
add/commit/push/fetch/pull/merge commands to get data into the repository.
The JSON file structure looks to be a mainstack key with the GUID value and
then GUID keys for each stack in the file that have all objects as a
dictionary. It should be relatively easy to turn it into an array. The
challenge will be dealing with diffs. The structure is something like this:
{
"guid of stack a": {
"object guid": {
}
},
"guid of stack b": {
"guid of stack b": {
"name": "Main Stack Name"
}
},
"mainstack": "guid of stack b"
}
On Thu, Sep 1, 2022 at 9:41 PM Pi Digital via use-livecode <
use-livecode@lists.runrev.com> wrote:
> 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@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@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@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> _______________________________________________
> 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
>
_______________________________________________
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
