Another Newbie Question

I know this has been asked and answered before, and I have looked
through the archives of this on Google.  That said, I'm asking again, if
you don't mind, because I can't always tell what version people are
referring to.  Being new to Dolphin, I'm not aware of the release
history.  Ok, enough preamble ;)

What is the (recommended, accepted, best, etc.) way to backup the
development image and your applications?  So far, I only have one
application, but I created two packages.  One to hold the application
and one to hold some graphic extensions I think are going to be useful
elsewhere.  Each package has some classes that belong to it, and some
loose methods from other classes.

In VisualAge ST, I keep a copy of the image after I get it configured to
a working condition I.E. IBM features, third-party class libs and my
common stuff.  Actually, I keep a few backups along the way to that
state.  I do tend to save my image with my applications, and I also
export my applications fairly often.

Of course, I haven't done any of that with Dolphin :(  mainly because I
thought it would take longer to get the point where I had code I cared
about.  I'm not so far that I can't start over with a clean slate, but
I'd apreciate some advice as to what approach works best, particularly
from version to version.  I am using Dolphin v5 Pro.

Thanks
Dan Antion

Dan,

There are probably several ways that people use but this is my
recommendation:

1) Assign all your work to packages and save these separately from your
image. If you are using Dolphin 5 then we'd recommend a scheme whereby you
save them into a directory with your name (or your company name) under the
directory where your image is kept. The packages should be the main place
where you keep your work. You can always rebuild your image from packages if
it becomes corrupted in any way.

2) You should regard your image as a temporary work environment but not a
place where your source is held on a permanent basis (that is the job of
packages). I tend to save my image every few minutes when working in Dolphin
(especially before trying anything risky). This means you can always restore
to your state of a few minutes past should you corrupt your in-memory image
in any way. If you need to roll back to a saved image then don't forget to
use Ian Bartholomew's changes browser (www.idb.me.uk) to bring back lost
changes from your recent change log (.chg).

Having said this, a fair few of our users *always* rebuild the image from
scratch (with an automatic script) each time they start Dolphin. They never
save out a modified image, only packages, and always start from afresh by
reloading all packages on image startup. This, however, is not my preferred
way of working.

3) I would also take a backup of your image (all three files .img, .chg and
.sml) on a daily basis, probably using your normal backup routine. This will
allow you to roll back to a fairly working state if your saved image becomes
corrupt and you have forgotten to save out your packages. This is useful
since it is possible (although rare) to save out a corrupt image that won't
load. This additional daily image backup can then be used to get out of
trouble. Once again you can use Ian's changes browser on the most recent
change log to bring back lost stuff into the backup image.  There are some
some addtional words about image management in the online help at:

http://www.object-arts.com/Lib/EducationCentre4/htm/managingprojects.htm

4) Ideally, you should think about checking your packages into a change
control system (if you have one). Dolphin supports file based source control
systems such as MS SourceSafe and CVS (although we have no direct experience
with the latter). The best way to do this is to enable PAX source format in
the Package Browser. This saves each package out as a number of separate
source files suitable for checking in to you SCCS. There are some additional
details in the D4 online help here:

http://www.object-arts.com/Lib/EducationCentre4/htm/sourcecontrol.htm

5) You may also like to consider using David Gorisek's Source Tracking
System which is an integrated change management system for Dolphin with
similar functionality to ENVY. You can find details of this here:
www.gorisek.com. If you choose this way of working you can avoid having to
save out individual package files since your source is held in an external
object database (Omnibase) repository.

I hope all this helps in some way.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

"Andy Bower" <[hidden email]> wrote in message
news:avnk2s$hordm$[hidden email]...
> 4) Ideally, you should think about checking your packages into a change
> control system (if you have one). Dolphin supports file based source
control
> systems such as MS SourceSafe and CVS (although we have no direct
experience
> with the latter). The best way to do this is to enable PAX source format
in
> the Package Browser. This saves each package out as a number of separate
> source files suitable for checking in to you SCCS. There are some
additional
> details in the D4 online help here:

I would just add, that checking packages in CVS is particulary usable when
one shares one utility package between different apps/images. In this
scenario, one checks out curent version of the package under the image dir
he is working currently, and checks in changes to the shared packages into
the cvs. This way it is easy to keep shared pac in sync between different
images.

Btw, I am quite happy how Dolphin  - CVS work together. It is not very tight
integration, but it works, and it especially usable for remote access to the
repository.

rush
--
http://www.templatetamer.org/

Andy Bower wrote:
This has been fairly easy to keep up with.  I have ended up with some
loose methods assigned to the wrong package, but that got sorted out.

>
> 2) You should regard your image as a temporary work environment but not a
> place where your source is held on a permanent basis (that is the job of
> packages). I tend to save my image every few minutes when working in Dolphin
> (especially before trying anything risky). This means you can always restore
> to your state of a few minutes past should you corrupt your in-memory image
> in any way. If you need to roll back to a saved image then don't forget to
> use Ian Bartholomew's changes browser (www.idb.me.uk) to bring back lost
> changes from your recent change log (.chg).

This is how I tend to work.  Regardless of Smalltalk, there seems to be
a split on this subject.  I just wanted to make sure I wasn't dancing
with the devil by working this way.

>
> Having said this, a fair few of our users *always* rebuild the image from
> scratch (with an automatic script) each time they start Dolphin. They never
> save out a modified image, only packages, and always start from afresh by
> reloading all packages on image startup. This, however, is not my preferred
> way of working.



I haven't looked at the change browser yet, that seems like a very nice
tool.

This is good to know, but I will probably wait on that.  Can you
manually save versions of packages and load them back in later.  I'm
thinking more along the lines of releasing a project, working on the
next version then finding that you have to fix a bug in the earlier
version.  Is this as simple as it seems, or would you need a source
managment or source tracking system for this.


> 5) You may also like to consider using David Gorisek's Source Tracking
> System which is an integrated change management system for Dolphin with
> similar functionality to ENVY. You can find details of this here:
> www.gorisek.com. If you choose this way of working you can avoid having to
> save out individual package files since your source is held in an external
> object database (Omnibase) repository.
>

This looks very nice.  Have releases of this tracked well with releases
of Dolphin?  I guess that's a general question I should ask separately,
but maybe I can get an answer here.  So far, I'm working well in this
environment, but (fortunately) I've added a lot of code from other
sources.  Has this code transitioned well from version to version of
Dolphin?

> I hope all this helps in some way.

Very much so!  Thanks.
Dan

Dan,

as of Dolphin 4.0 I have been included in the Dolphin early beta programme.
Usually a new version of STS is released within 2 weeks right after a new
major Dolphin version is released.

Current version of STS has the following features:
- versioning of methods, classes and package
- multi-user or multi-image development on a single code repository
- adds a concept of projects which are similar to ENVY configuration maps
- ability to load only partial code from repository
- browsing code in the repository without loading it (shadow editions)
- comparing versions in the repository with each other
- comparing loaded code (packages, classes, methods) with versions in the
repository
- importing a package into repository without loading it first into the
image (Dolphin 4.0 and 5.0 packages)
- partial loading of packages which would not load otherwise (compiles what
it can and leaves the rest for manual loading)
- importing VisualWorks 5i.x/7.x parcel files as Dolphin packages into
repository (*.PST)
- importing VAST application file-outs as Dolphin packages into repository
(*.APP)

With STS one can work in the following manner:
- always begin with an empty image
- load the latest project version into the image
- when your dev session ends version the project and all packages in the
project
- exit without saving image

This way you can work on multiple projects or multiple versions of the same
project using a single image file. All your code is nicely stored in the
repository.

Best regards,

David Gorisek
http://www.gorisek.com


"Dan Antion" <[hidden email]> wrote in message
news:[hidden email]...
> > 5) You may also like to consider using David Gorisek's Source Tracking
> > System which is an integrated change management system for Dolphin with
> > similar functionality to ENVY. You can find details of this here:
> > www.gorisek.com. If you choose this way of working you can avoid having
to
> > save out individual package files since your source is held in an
external