STS Project Usage?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

STS Project Usage?

TimM-3
This post got lost in another thread, so I want to ask it again as there are
a few power STS users here. I think I'm starting to understand the model of
STS, and now I understand why Andy asked STS users what there usage patterns
were....

So it seems that STS is like Envy, in that everything I change will be
recorded in
omnibase (at the method level)? And that the Package Editions just give me
an entry point to lining up all of those method editions (and class changes)
into a named set?

And if this is true, then projects are a grouping of Package Editions, so
that I can load all of them en-masse too? It seems this way from the Wiki
docs andy posted a link to.

But I'm still trying to understand how you handle the situation of the
recent Image Live update? e.g. When I started STS the first time it
suggested adding all the current image classes - which I did. But it didn't
seem to create a new project for me? Should I have done this?

E.g. if I apply the Live Update - how can I store that as a new base
starting point (so that if I
need to create a new image I can start from that point)? I assume all the
methods will have new editions - but now there will be some packages that OA
will
have updated - so if I had created a "Project" and added all of the original
image
packages into it - and then this would give me the hook to find out what had
changed so that I could create a Patch1 project?

But then what about any new packages they add - how do I figure out what
would then go into my new Patch1 project? It looks like I would just have to
carefully track this myself.


Tim


Reply | Threaded
Open this post in threaded view
|

Re: STS Project Usage?

David Gorisek-2
You don't have to version OA code into repository. Also, there is no way
STS could automatically organize OA code into projects. Even if the base
Dolphin code itself would be stored as STS project it would currently be
impossible to (re)load parts of it simply because while the e.g.
compiler code would be loading another version of itself it would also
be changing itself.

So, projects are primarily meant for your own code. You can create a
project for all your packages that go into one end-user application and
then you can group package versions together into a project version for
each version of the application that you deliver.

Best regards,

David Gorisek


TimM wrote:

> This post got lost in another thread, so I want to ask it again as there are
> a few power STS users here. I think I'm starting to understand the model of
> STS, and now I understand why Andy asked STS users what there usage patterns
> were....
>
> So it seems that STS is like Envy, in that everything I change will be
> recorded in
> omnibase (at the method level)? And that the Package Editions just give me
> an entry point to lining up all of those method editions (and class changes)
> into a named set?
>
> And if this is true, then projects are a grouping of Package Editions, so
> that I can load all of them en-masse too? It seems this way from the Wiki
> docs andy posted a link to.
>
> But I'm still trying to understand how you handle the situation of the
> recent Image Live update? e.g. When I started STS the first time it
> suggested adding all the current image classes - which I did. But it didn't
> seem to create a new project for me? Should I have done this?
>
> E.g. if I apply the Live Update - how can I store that as a new base
> starting point (so that if I
> need to create a new image I can start from that point)? I assume all the
> methods will have new editions - but now there will be some packages that OA
> will
> have updated - so if I had created a "Project" and added all of the original
> image
> packages into it - and then this would give me the hook to find out what had
> changed so that I could create a Patch1 project?
>
> But then what about any new packages they add - how do I figure out what
> would then go into my new Patch1 project? It looks like I would just have to
> carefully track this myself.
>
>
> Tim
>
>


Reply | Threaded
Open this post in threaded view
|

Re: STS Project Usage?

TimM-3
> STS could automatically organize OA code into projects. Even if the base
> Dolphin code itself would be stored as STS project it would currently be
> impossible to (re)load parts of it simply because while the e.g. compiler
> code would be loading another version of itself it would also be changing
> itself.
>
> So, projects are primarily meant for your own code.

I see - so why does it prompt you to put all the Packages into STS when you
first start up?

Actually I think that this might be useful - because there is no way to have
soft breakpoints in Dolphin so getting rid of halts or Transcript print: 's
could mean just reloading the base OA package...  but then as you mention do
you hit compiler problems?

So is this a definite no-no.... I thought I read somewhere that others did
this, but as you said, maybe I should just focus on my own code and just
periodically dump the image and reload from a fresh one.

Blair/Andy - it might be worth just documenting an easy way to get going
with this for people - and consider whether you should have that initial
"Put all packages into STS" message when you first use it.

Tim


Reply | Threaded
Open this post in threaded view
|

Re: STS Project Usage?

David Gorisek-2
Modifications to base image methods are exactly why I have put the
prompt to version all Dolphin classes into repository.

So, when a Dolphin package has a change marker in front of it I can use
"Compare with another package edition" to see what changes there are.

But this is done on a package and not on a project level.

Of course, if more people think that having a possibility to quickly see
ALL the modifications to the base image we could make something better
than what exists now.

Best regards,

David Gorisek



TimM wrote:

>>STS could automatically organize OA code into projects. Even if the base
>>Dolphin code itself would be stored as STS project it would currently be
>>impossible to (re)load parts of it simply because while the e.g. compiler
>>code would be loading another version of itself it would also be changing
>>itself.
>>
>>So, projects are primarily meant for your own code.
>
>
> I see - so why does it prompt you to put all the Packages into STS when you
> first start up?
>
> Actually I think that this might be useful - because there is no way to have
> soft breakpoints in Dolphin so getting rid of halts or Transcript print: 's
> could mean just reloading the base OA package...  but then as you mention do
> you hit compiler problems?
>
> So is this a definite no-no.... I thought I read somewhere that others did
> this, but as you said, maybe I should just focus on my own code and just
> periodically dump the image and reload from a fresh one.
>
> Blair/Andy - it might be worth just documenting an easy way to get going
> with this for people - and consider whether you should have that initial
> "Put all packages into STS" message when you first use it.
>
> Tim
>
>