Studio – Github
Hi Clifford,
No, it’s not specific to git. The key is that the source is exposed as plain text which git, mercurial, subversion, perforce, or even CVS can handle much better than a binary lbs file.
Alex
> On Oct 5, 2017, at 13:22, Clifford Ilkay <cilkay@gmail.com> wrote:
>
> 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
_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com
