Studio – Github

Is it really “git export” or just JSON export? I didn’t see anything in the
source code of the OmnisTAP repo that Alex shared that would make it
git-specific. I could store that source code in any revision control
system, e.g. Mercurial.

Regards,

Clifford Ilkay

+ 1 647-778-8696

On Thu, Oct 5, 2017 at 10:50 AM, Doug Easterbrook <doug@artsman.com> wrote:

> by the way of history on git export — it was a topic of conversation at
> the last Euromnis.
>
>
> a case was made for the need to work in distributed teams and how git
> would support that very effectively (or any external version control of
> preference, is you are subversion fan).
>
> plus the need for automatic builds and testing using the likes of jenkins,
> etc.
>
>
> Bob & Bob listened .. as did the new owners, and to their vast credit,
> they understood why this was needed and how it could help Studio within the
> enterprise.
>
> It positions Studio to play even better in the enterprise space where
> there are lots of ancillary tools that are free/ope nsource that are in
> widespread use.
>
> plus .. an open repository tool like git will help the studio community
> share minor libraries if they wish. eg, we have a built a performance
> analyzer that we know some people use. its a separate library, self
> enclosed. now we can put it into git and others can get it, and/or
> submit enhancements.
>
>
> it is an excellent example of how the core studio development are able to
> respond to the changing need of the developer community
>
>
> great Kudo’s to Omnis for implanting git export. it truly opens a lot
> of doors to a lot of supporting toolsets to automate parts of application
> development process
>
>
>
> Doug Easterbrook
> Arts Management Systems Ltd.
> mailto:doug@artsman.com
> www.artsman.com
> Phone (403) 650-1978
>
> > On Oct 5, 2017, at 8:37 AM, Doug Easterbrook <doug@artsman.com> wrote:
> >
> > as alex says… the files are spread out.
> >
> >
> > essentially there is a folder for each object (a window, or object, or
> file, or table class)
> >
> > in that folder, there is a file for the variables and one file for each
> method.
> >
> > they are all pretty-printed for proper indentation, etc .. which is
> exactly the way git likes it.
> >
> >
> >
> >
> >
> >
> > Doug Easterbrook
> > Arts Management Systems Ltd.
> > mailto:doug@artsman.com
> > www.artsman.com
> > Phone (403) 650-1978
> >
> >> On Oct 5, 2017, at 8:21 AM, Clifford Ilkay <cilkay@gmail.com> wrote:
> >>
> >> Hi Alex,
> >>
> >> That should make it feasible to generate Omnis libraries without the
> use of
> >> the Omnis IDE. (It could also make it easier to get out of Omnis.)
> >>
> >> Is the export one big JSON file, one JSON file per class, or something
> else?
> >>
> >> Regards,
> >>
> >> Clifford Ilkay
> >>
> >> + 1 647-778-8696
> >>
> >> On Thu, Oct 5, 2017 at 10:00 AM, Alex Clay <aclay@mac.com> wrote:
> >>
> >>> Hi Clifford,
> >>>
> >>> Absolutely yes. The only tricky part is managing multiple libraries
> that
> >>> share superclasses, design tasks, or external file classes. In those
> >>> instances, you need a copy of the remote library open for the import to
> >>> successfully build a .lbs from the JSON export.
> >>>
> >>> Alex
> >>>
> >>>> On Oct 5, 2017, at 09:57, Clifford Ilkay <cilkay@gmail.com> wrote:
> >>>>
> >>>> The JSON that is exported from a library, is it a complete
> representation
> >>>> of the library with all classes, methods, and attributes of those
> >>> classes?
> >>>> In other words, can I take a fresh library, import that JSON, and
> have a
> >>>> fully-functioning library that works exactly the same as the original
> >>>> library from which the export was done?
> >>>>
> >>>> Regards,
> >>>>
> >>>> Clifford Ilkay
> >>>>
> >>>> +1 647-778-8696
> >>>>
> >>>> On Thu, Oct 5, 2017 at 9:22 AM, Doug Easterbrook <doug@artsman.com>
> >>> wrote:
> >>>>
> >>>>> hi Andrea:
> >>>>>
> >>>>> Alex is right — two people can be working on the same class and its
> not
> >>> a
> >>>>> problem.
> >>>>>
> >>>>> you have to look at the mindset of traditional version control
> systems
> >>>>> (the Omnis VCS is modelled after them). You are familiar with it ..
> >>>>> — they are in a central repository
> >>>>> — you take the classes you want
> >>>>> — you prevent others from change them
> >>>>> — you fix
> >>>>> — you put them back
> >>>>>
> >>>>>
> >>>>> often you take mote classes than you need, in case you have to fix
> >>>>> something up the inheritance tree.and then you have to figure out
> what
> >>> has
> >>>>> changed before you put it back.
> >>>>>
> >>>>> and the reason you do that is that the problem/solution is never
> where
> >>> you
> >>>>> think it is going to be. What that does is lock others in a team
> >>> out of
> >>>>> changing something in the same class.
> >>>>>
> >>>>>
> >>>>>
> >>>>> with git, the mindset is a free-for-all.. Everybody changes what
> they
> >>>>> need, when they need.
> >>>>>
> >>>>>
> >>>>> While it may seem like anarchy, it is really isn’t. there is a day
> of
> >>>>> reckoning AT TIME OF CHECKIN as follows:
> >>>>>
> >>>>> I change class A, you change class B. we can both push up the
> changes
> >>> and
> >>>>> there is no conflict. git likes that. not much different than
> using
> >>> a
> >>>>> traditional VCS, except you didn’t check out.
> >>>>>
> >>>>>
> >>>>> we both change Class A, I change method 1 (eg build a list) and
> you
> >>>>> change method 2 (sort a list). There is still no conflict, git
> likes
> >>>>> it. both of us can check in. VCS would not like it.
> >>>>>
> >>>>>
> >>>>> we both change class A and we both change the same method. Git
> says
> >>> ..
> >>>>> first check in wins and the second person to check in is faces with
> >>>>> comparing the difference in that one method .. to decide how to
> merge in
> >>>>> their changes.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> We’ve used git ofr other projects for a number of years — (to manage
> C
> >>>>> code, html pages, python, config files for setup of our application —
> >>> lots
> >>>>> of things), and I’d far rather use it that a centralized VCS.
> >>>>>
> >>>>> developers are far more productive — they see a problem and fix it.
> >>>>> and the funny part, is that there is rarely a conflict.
> >>>>>
> >>>>>
> >>>>>
> >>>>> as soon as we can get everything to studio 8, we are gonig to use
> git..
> >>>>> it has realy great
> >>>>> — diff features (comparing the changes)
> >>>>> — blame features (who exactly is responsible for each line of code in
> >>> each
> >>>>> method – eg I did line 1, you did lines 3 to 5, I did line 6)
> >>>>> — versioning features (so you can be working on many different things
> >>> and
> >>>>> then build a release that is only of finished stuff)
> >>>>> — and you can automate it with code building and testing tools.
> >>>>>
> >>>>>
> >>>>> I really can’t wait.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On Oct 5, 2017, at 1:34 AM, Andrea Zen <a.zen@athesiavr.it> wrote:
> >>>>>>
> >>>>>> How is simultaneous development managed? I mean what now is the
> locking
> >>>>> of classes in the VCS, when you “check out to modify”, that prevents
> >>>>> developers to work both on the same class.
> >>>>>>
> >>>>>> Andrea Zen
> >>>>>>
> >>>>>>
> >>>>>>> —–Original Message—–
> >>>>>>> From: omnisdev-en [mailto:omnisdev-en-bounces@lists.omnis-dev.com]
> On
> >>>>>>> Behalf Of Alex Clay
> >>>>>>> Sent: Wednesday, October 4, 2017 8:40 PM
> >>>>>>> To: OmnisDev List – English <omnisdev-en@lists.omnis-dev.com>
> >>>>>>> Subject: Re: Studio – Github
> >>>>>>>
> >>>>>>> Hi Andrew,
> >>>>>>>
> >>>>>>> Instead of checking out classes, you simply make the changes you
> need.
> >>>>>>> When ready, export the library to JSON. You then commit it like any
> >>>>> other
> >>>>>>> code – add new files, remove deleted ones, and commit and push when
> >>>>>>> ready. When you need to integrate with another developer’s work,
> pull
> >>>>> the
> >>>>>>> remote repository into your local copy. In Studio, import the JSON
> >>> code
> >>>>> into a
> >>>>>>> new library and voila, you have the latest copy!
> >>>>>>>
> >>>>>>> Mix this with feature branching and you have a slick setup for
> >>> multiple
> >>>>>>> developers…and it’s handy for single devs, too.
> >>>>>>>
> >>>>>>> I’m covering how to do this at EurOmnis in 10 days or so in case
> >>> you’ll
> >>>>> be
> >>>>>>> there. 🙂
> >>>>>>>
> >>>>>>> Alex
> >>>>>>>
> >>>>>>>> On Oct 4, 2017, at 14:35, Andrew Stolarz <stolarz@gmail.com>
> wrote:
> >>>>>>>>
> >>>>>>>> Hi Alex,
> >>>>>>>>
> >>>>>>>> Thanks I will look into it.
> >>>>>>>>
> >>>>>>>> Im used to the old school omnis VCS process, check in – check out
> >>>>>>>> within Omnis.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> How does this work for you using GitHub and JSON exports? ie.
> what is
> >>>>>>>> the process like to “check in / check out” components?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Andrew
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, Oct 4, 2017 at 2:26 PM, Alex Clay <aclay@mac.com> wrote:
> >>>>>>>>
> >>>>>>>>> Hi Andrew,
> >>>>>>>>>
> >>>>>>>>> Your best bet is to jump to Studio 8.1 so you can export your
> >>>>>>>>> libraries as JSON. We have a couple projects on GitHub that host
> >>> both
> >>>>>>>>> this JSON source and then compiled .lbs files:
> >>>>>>>>>
> >>>>>>>>> github.com/suransys/omnistap
> >>>>>>>>> <github.com/suransys/omnistap
> >>>>>>>>>>
> >>>>>>>>> github.com/suransys/omniscli
> >>>>>>>>> <github.com/suransys/omniscli
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Alex
> >>>>>>>>>
> >>>>>>>>>> On Oct 4, 2017, at 14:21, Andrew Stolarz <stolarz@gmail.com>
> >>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Just curious if anyone is using Omnis libraries with Github? if
> so,
> >>>>> how?
> >>>>>>>>>>
> >>>>>>>>>> or we locked into using the Omnis VCS?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Andrew
> >>>>>>>>>>
> >>>>>>> __________________________________________________________
> >>>>>>> ___
> >>>>>>>>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> __________________________________________________________
> >>>>>>> ___
> >>>>>>>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>>>>>>>
> >>>>>>>>
> >>>>>>> __________________________________________________________
> >>>>>>> ___
> >>>>>>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>>>>>
> >>>>>>> __________________________________________________________
> >>>>>>> ___
> >>>>>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>>>> _____________________________________________________________
> >>>>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Doug Easterbrook
> >>>>> Arts Management Systems Ltd.
> >>>>> mailto:doug@artsman.com
> >>>>> www.artsman.com
> >>>>> Phone (403) 650-1978
> >>>>>
> >>>>>
> >>>>> _____________________________________________________________
> >>>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>>>
> >>>>>
> >>>> _____________________________________________________________
> >>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>
> >>> _____________________________________________________________
> >>> Manage your list subscriptions at lists.omnis-dev.com
> >>>
> >> _____________________________________________________________
> >> Manage your list subscriptions at lists.omnis-dev.com
> >
> > _____________________________________________________________
> > Manage your list subscriptions at lists.omnis-dev.com
>
>
> _____________________________________________________________
> Manage your list subscriptions at lists.omnis-dev.com
>
>
_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com