More D6 News...

--
Andy Bower
Dolphin Support
www.object-arts.com

Folks,

We've some exciting news regarding D6 for you. Over the last few weeks
we've been working with David Gorisek of IT Consulting and have now
come to an agreement where Object Arts will license his Source Tracking
System for inclusion in the Dolphin 6 Professional product. For those
of you who don't know about STS you can read about it here:

http://wiki.gorisek.com/WikiDoc/WikiPage?page=Source+Tracking+System&lan
g=English

We already have the basic STS system working in D6 and so we are hoping
that this new set of facilities will not delay the release of the new
version by too much.

I do have a question to ask those of you who are already STS veterans,
however.  Could you reply to this newsgroup post with a brief
description of how you use STS with Dolphin?  For example, do you
version the entire system (including the base classes) into the
repository or do you just add your own code? Also, when do you choose
to create new versions in the repository? Do you effectively use it to
replace an image save and version all of the changes when you exit
Dolphin and reload them when you next start up the image. Or do you use
the image "normally" as a temporary repository for your work and only
version it to the STS database once a major change is complete?

The reason for asking is that we are preparing some some workflow
documentation that should really include some recommendations on how
the STS facility should be used in conjunction with the image and
package files.

Anyway, I hope you will agree this is exciting news and we must thank
David Gorisek for producing such an excellent add-on for the Dolphin
environment.

Best regards,

--
Andy Bower
Dolphin Support
www.object-arts.com

Andy,
"Andy Bower" <[hidden email]> wrote in message
news:[hidden email]...
> Folks,
>
> We've some exciting news regarding D6 for you. Over the last few weeks
> we've been working with David Gorisek of IT Consulting and have now
> come to an agreement where Object Arts will license his Source Tracking
> System for inclusion in the Dolphin 6 Professional product. [...]
That's really good news!  The only downside of using STS has been having to
wait to use new versions of Dolphin until the new version of STS was out.

[...]
> description of how you use STS with Dolphin?  For example, do you
> version the entire system (including the base classes) into the
> repository or do you just add your own code? [...]
I just add my own code now.  I tried versioning the whole system when I
first got STS, but it took a long time and everything got my name on it; it
was harder to tell where I had actually modified methods.  I still imagine
it would be nice to have the whole system in the repository, but maybe it's
impractical.

> to create new versions in the repository? Do you effectively use it to
> replace an image save and version all of the changes when you exit
> Dolphin and reload them when you next start up the image. Or do you use
> the image "normally" as a temporary repository for your work and only
> version it to the STS database once a major change is complete?
I start with a slightly modified image (STS and Ian B's excellent
utilities), then create a development image pre-loaded with the packages I'm
unlikely to change.  When I'm working, I start my development image, then
load in the latest versions of few packages I'm actually working on.  I
version packages and update projects whenever (1) I've made significant
progress on something or (2) I'm about to do something that might crash the
image.  I only version projects when I am satisfied that a new version of a
program is ready for release.  (I also added some code to STS to highlight
older versions of packages within projects and hacked Ian's
SmalltalkWorkspace>>showUndefined: to deal with a status bar message
conflict with STS.)  That's the same way I always worked with package files,
too, but I suspect it's because I use lots of IDispatch subclasses.  Early
on I found things more reliable if it didn't save the image with any of them
hanging around.  (FWIW, I do tend to leave my image running for days at a
time, even longer if I'm only using it as a sort of awk replacement.)

[...]
> Anyway, I hope you will agree this is exciting news and we must thank
> David Gorisek for producing such an excellent add-on for the Dolphin
> environment.
This is indeed exciting.  Thanks to both David and OA for this.

Best,

Don

>
> Best regards,
>
> --
> Andy Bower
> Dolphin Support
> www.object-arts.com

Oh, that's great!!!

I'm reading PPJM(Pragmatic Programmer: From Journeyman to Master).
So I cought that Source Tracking System is very valuable.
STS will integrated in D6... that 's great!

Although I have no idea about STS, I can tell that D6 is very very
strong
and productive Development Environment!

OA, Please do your best until final release time!

Andy Bower wrote:
> We've some exciting news regarding D6 for you. Over the last few weeks
> we've been working with David Gorisek of IT Consulting and have now
> come to an agreement where Object Arts will license his Source Tracking
> System for inclusion in the Dolphin 6 Professional product.

That's great news -- except that I purchased an STS upgrade (after
having let my subscription lapse for a few years) less than 1.5 months
ago.  Bad timing.

> [...] do you
> version the entire system (including the base classes) into the
> repository or do you just add your own code?

I version everything.

> Also, when do you choose
> to create new versions in the repository? Do you effectively use it to
> replace an image save and version all of the changes when you exit
> Dolphin and reload them when you next start up the image. Or do you use
> the image "normally" as a temporary repository for your work and only
> version it to the STS database once a major change is complete?

I still save the image (I even save the packages, but only because my
flaky computer has made me paranoid).  I version my changes frequently,
though I try to do so only when a feature is complete.  I may version
work in progress if I want to the option to roll back the changes I'm
about to make (but an image save is usually an adequate substitute).

I recently started using Project Editions to group related package versions.

Dolphin 6 will be amazing -- the most "polished" Smalltalk dialect
available.

Cheers,
-- Aaron

"Dolphin 6 will be amazing -- the most "polished" Smalltalk dialect
available. "

I totally agree.

We use STS since a couple of years and it is an excellent product.

* We version also all the Dolphin System code, so we can easily revert the
the original system method, see what exactly has been patched and compare
different Dolphin System code versions. We sometimes had the problem, that
our code didn't work, when we switched to a new patch version of Dolphin.
STS helped a lot to find these problems.

* We try to publish/version as soon as possible We often release into an
open edition of the project and version the project when all tests are
green. It should be always possible to reload the current state from a fresh
base image with one click.

* A simple improvement would be nice: We sometimes have several open
development lines (open project editions). It would be nice to add comments
(like packge comments) to the project where I can document, what has been
changed and into which edition should be released (open editions do not have
names compared to versioned editions of projects).

Regards

Carsten

"Andy Bower" <[hidden email]> schrieb im Newsbeitrag
news:[hidden email]...

On 14 Sep 2005 08:28:38 GMT, Andy Bower <[hidden email]> wrote:

> Folks,
>
> We've some exciting news regarding D6 for you. Over the last few weeks
> we've been working with David Gorisek of IT Consulting and have now
> come to an agreement where Object Arts will license his Source Tracking
> System for inclusion in the Dolphin 6 Professional product.

Looks like Christmas will come early this year ...

>
> We already have the basic STS system working in D6 and so we are hoping
> that this new set of facilities will not delay the release of the new
> version by too much.

... or will it, Andy? ;->

>
> I do have a question to ask those of you who are already STS veterans,
> however.  Could you reply to this newsgroup post with a brief
> description of how you use STS with Dolphin?

I would not call me veteran, but here we go:
fresh install -> patches -> omnibase -> sts, now version everything
(and try to store this "virgin dev environment" better than last time :-)

 From now on sts serves as "arbitrary time-stamped undo buffer".

Packages are saved to pac files when I want to try out, if deployment to .exe
and the executable work as expected, deployment itself is done from a slightly
patched image (removed one annoying dialog after stripping) using a prestart.st
file to automate package loading.

Packages are versioned after
- a new feature works
- or a bug is fixed
- with a comment summarizing the change

>
> Anyway, I hope you will agree this is exciting news and we must thank
> David Gorisek for producing such an excellent add-on for the Dolphin
> environment.

I can't stand it any more ... must get ... D6 ... now ...

:-)

s.

I tend to swap between using my desktop machine and my laptop so I use
STS to version work at the end of each session, then if I start
working on the other computer I just load the latest packages into
that image.

When I first installed STS I did version the entire system, including
the STS packages themselves. I found a couple of bugs in STS so I
versioned off the updated packages.

I use the Project Editions browser to group together all the packages
I'm currently working on. I update this at the end of each session to
make it easier to load all the correct package versions when I move to
my other machine.

I also save .PAC files when I reach a milestone. These milestone PAC
files get stored in CVS along with my base image (the basic Dolphin
image plus Omnibase, STS and various other extras/goodies I use). My
working image gets put into CVS at each milestone as well. It also
helps if I reinstall my machine for any reason, I can go into CVS and
check out an entire Dolphin environment up to date at my latest
milestone.

STS is a great boon in allowing me to look at/compare old versions of
methods and classes, gives me a history of what I did at various
points in time and allows me to go back in very fine detail to earlier
versions when I make a really big cock-up.

Having been a long time VAST/Envy  user I really appreciate the
facilities that STS provides. It is IMHO a most essential new feature
to Dolphin. The lack of a version management system has featured very
much in my work's lack of interest in Dolphin as a development
environment (We use VSE and VAST currently but are looking into
alternatives as VSE is out of date and VAST's future is a little up in
the air).

The inclusion of STS as standard may make my boss change his mind
about Dolphin (especially as the only potential upgrade we have at
work at the moment is the horrendously expensive VW), although it
could still do with some work to bring it up to ENVY standard.

I was looking forward to upgrading to D6 anyway but now my mouth is
really watering. Can't wait...........

Regards

The Brave Sir Robin.

On 14 Sep 2005 08:28:38 GMT, "Andy Bower"
<[hidden email]> wrote:


>We already have the basic STS system working in D6 and so we are hoping
>that this new set of facilities will not delay the release of the new
>version by too much.
>
>I do have a question to ask those of you who are already STS veterans,
>however.  Could you reply to this newsgroup post with a brief
>description of how you use STS with Dolphin?  

I'm just starting with STS, but I version _everything_.

This is great news. I consider STS to be an integral part of Dolphin and
will be pleased to see it included.

While I have versioned the entire system that is primarily because it is the
default behavior. I rarely change any base classes (though this has been
helpful for finding out what changes I may have made accidently).

I rarely save my Dolphin image, but version the packages each time I make a
change and reload them each time I launch.

James Foster

"Andy Bower" <[hidden email]> wrote in message
news:[hidden email]...

That's great that STS will be included!!

I've been using STS for over 4 years, and wouldn't want to work now in
Dolphin without it.

Andy Bower wrote:
 > Could you reply to this newsgroup post with a brief
 > description of how you use STS with Dolphin?

I version all the packages in the base system, setting the developer to
'Object Arts' before doing so. Makes it easier to sort out changes later
on... Did I change a method temporarily while debugging and then put it
back? Did I make a change that I should now put back? Did I add a method
that should be moved to a package of my own as a loose method? Or, did I
make a change that should be made into a "patch" of the base image --
saved with a set of files used to rebuild the image from source,
re-versioning the package in STS so that particular change won't show up
the next time.

For my own packages, I generally version all changes when the current
task is done. Depending on the size of the task, this could be anywhere
from an hour or two, to a day or two.

While working I make use of image saves. Loading from STS each time just
wouldn't be viable -- it currently takes 33 minutes (on this doddering
667MHz machine) to build a working image from the base image and STS. [I
keep meaning to do some profiling to see where the time goes, but just
haven't gotten around to it].

I no longer make use of package files, except for filing in from or
sending to 3rd parties. (Did before STS, when I was using CVS).

Periodically build a fresh image. At the end of a day, if new work has
been done, tasks are complete and all changes are versioned (on average
it's been 3 times a week) I'll start a batch process. It builds a fresh
working image -- starting from the base image, filing in STS, filing in
some base patches, installing some 3rd party package files, and loading
the latest package editions from STS. It then runs all the unit and
acceptance tests, strips the image for deployment, makes the
installation file, uploads it to our server for possible release, makes
disk backups, and replaces the working image with the freshly made one.

The next day, I just start with the fresh working image.

Thus goes my process. Hope this was useful.
-Bill


--
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

Bill Dargel wrote:

> Thus goes my process. Hope this was useful.

It's been interesting to see how wide the range of working practises is
(described both here and in the beta list).  I don't envy Andy trying to
distill it all down into advice for newcomers ;-)

    -- chris

Very nice description bill - all you need to do now is hook in the lava
lamps ;-)  (see:
http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Monitor/Devices/BubbleBubbleBuildsInTrouble.rdoc)

Actually - why is it that you don't do this automatically when you check in
(e.g. just kick off your batch script). I am assuming if your tests fails -
the new image gets removed and you get notified somehow?

Thanks for sharing this - coming back to Smalltalk from a Java / C# world I
was wondering if anyone did any continous builds (in the  - deploy my
application sense) - so its nice to hear I have something to aspire to.

Tim

"Bill Dargel" <[hidden email]> wrote in message
news:[hidden email]...

Chris, Andy,

> It's been interesting to see how wide the range of working practises is
> (described both here and in the beta list).  I don't envy Andy trying to
> distill it all down into advice for newcomers ;-)

Good point, but I think the easiest way would be to write it up as
comparison/contrast of approaches ranging from (analogs to) "image
saver" to "build a clean image saved packages every time".  Post a link
to the result, and let the various contributors disagree as they see
fit; Andy can then edit or add new sections as needed; iterate to
background noise levels or Andy's frustration point :)

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

TimM wrote:
> Actually - why is it that you don't do this automatically when you check in
> (e.g. just kick off your batch script). I am assuming if your tests fails -
> the new image gets removed and you get notified somehow?

In my case, checking things in and firing up a build involve somewhat
different decision criteria. So the separate choice really makes sense.
Since a given programming "episode" sometimes ends up making changes in
as many as a dozen or so packages, I'd want to wait until all changes
had been versioned (certainly doable though). [I could probably stand to
at least review how my code gets divided up into packages. Though
affecting multiple packages is still bound to happen a lot. Since I
separate tests from production code, and shared code from server code
from client code, new features can often touch all six areas].

Though probably the biggest reason that I keep check-in and build
separate is that the build gets done on the same machine that I do most
of my development work. :-( Since the complete build now takes more than
two hours, I like to fire it up when I'm done for the day. It really
wants to have the machine to itself -- especially since the tests
include a few regression tests that are scraping the screen and
comparing a window's contents with what's expected (gets messed up if
another application's window has occluded the window under test).

If unit tests fail, then the rest of the batch script does get skipped
(acceptance test failures merely get logged) -- so it doesn't replace
the working image with the new fresh image. But the fresh image is
available should I want to try things in the exact environment that failed.

As far as notification goes, the DOS batch window remains open with a
success/failure indication. Or remotely, I can open the log file that
the batch script (and test results) get written to. That also allows for
checking on it's overall progress. Though I like the lava lamp idea. ;-)

--
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA