Another Newbie Question 
Author Message
 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



Wed, 29 Jun 2005 05:47:12 GMT  
 Another Newbie Question
Dan,

Quote:
> 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.

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
---



Wed, 29 Jun 2005 07:13:44 GMT  
 Another Newbie Question

Quote:
> 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/



Wed, 29 Jun 2005 20:11:05 GMT  
 Another Newbie Question

Quote:

> Dan,

>>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.

> 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.

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.

Quote:

> 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.

- Show quoted text -

Quote:

> 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:

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

Quote:

> 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

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.

Quote:
> 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?

Quote:
> I hope all this helps in some way.

Very much so!  Thanks.
Dan

- Show quoted text -

Quote:

> Best Regards,

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



Wed, 29 Jun 2005 20:29:26 GMT  
 Another Newbie Question
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


Quote:
> > 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?



Fri, 01 Jul 2005 15:07:46 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Newbie Question (Was: Newbie Question...)

2. Not a newbie, but a newbie question...

3. Trivial Newbie Question (Newbie)

4. Newbie Question: Realbasic Question

5. Yet another question on system calls(newbie question)

6. A few more newbie questions..

7. Newbie question about worth of specializing in Smalltalk

8. Very Newbie questions

9. Newbie question

10. newbie questionS

11. newbie question

12. newbie question on treemodel

 

 
Powered by phpBB® Forum Software