Image versus package savers?

As far as version control for applications within in your image, would
you say that you prefer backing up your whole image frequently and
exporting then backing up your packages frequently, or vice versa?

If you are using Subversion to do so, do you keep two separate
repositories: one for mostly binaries (like system images, graphical
images) and one for primarily text files (exported packages, text
files)?

I typically do both. Early on, I ignore images and work exclusively
with packages. Once I'm beyond the "testing" phases of worksheets, etc,
then I start working on the image. However, even in the image,
everything (for me) is still package based. I've lost images, and being
able to remake the image quickly from the packages has been very handy.

Note: I've only just recently purchased the Dolphin pro version
(whee!), and I haven't been dealing if very large codebases yet (in
Smalltalk), so my approach will probably vary some in the future. Also,
I transfer the packages from machine to machine by means other than
thumbdrive/disk, so having my code saved in a tight format is nice
(where the image files can be quite bloated).

Jeff M.

Griff wrote:
> As far as version control for applications within in your image, would
> you say that you prefer backing up your whole image frequently and
> exporting then backing up your packages frequently, or vice versa?
>
> If you are using Subversion to do so, do you keep two separate
> repositories: one for mostly binaries (like system images, graphical
> images) and one for primarily text files (exported packages, text
> files)?

Griff wrote:
> As far as version control for applications within in your image, would
> you say that you prefer backing up your whole image frequently and
> exporting then backing up your packages frequently, or vice versa?
>
> If you are using Subversion to do so, do you keep two separate
> repositories: one for mostly binaries (like system images, graphical
> images) and one for primarily text files (exported packages, text
> files)?

If you search for the keyword "bonkers" (sorry Andy - it's just the
easiest way to find the thread), you will find some healthy debate on
the subject.  I tend to use an image for a very long time, _but_ I have
some fairly strict rules for when to abandon w/o saving.  Knowing that,
I set up to try something risky (see below), save, and then give it a
shot.  If all DLL breaks loose, then I learn what I can in the debugger
and bail out, hopefully fixing it in the freshly reloaded image.  Others
build a new image from packages every day (sometimes more frequently).

Things that I consider risky include: newly changed external
interfacing; failure of an MVP triad to open correctly; note that you
should never save an image if the dreaded prim g2 garbage collector (or
whatever it's called) walkback appears.  The latter might not apply in D6??

An obvious advantage of building frequently is that you will discover
and fix install script oversights.

Have a good one,

Bill

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

Griff,

> As far as version control for applications within in your image, would
> you say that you prefer backing up your whole image frequently and
> exporting then backing up your packages frequently, or vice versa?

I /never/ back up an image -- to much risk of inconsistency with backed-up
packages.  (Equally, I suppose, one could refuse to back up packages if one
were backing up the image regularly).  I rebuild my working image from packages
only when I am forced to -- perhaps once or twice a year -- so I save packages
out to file /vastly/ more frequently than I load from file.

FWIW.  I use the packages files as the ultimate repository of code.  They get
backed up carefully (when I remember).  I don't use Subversion (or anything
else) for versioning those files, but I do use STS to provide a history (and
partial additional backup) of the packages' developing states.   The STS
repository itself is also GCed and backed-up (again, when I remember).

I save packages out frequently (minutes rather than hours or days).  I version
packages in STS whenever the code reaches some sort of plateaux (which includes
immediately after small bugfixes).   I don't allow any of the following
situations to occur except in very rare (and /very/ conscious) circumstances:
    - The package on disk is more recent than the
      package embedded in the latest saved image state.
    - The package on disk is more recent than the
      package in the current running image.
    - STS holds a version of a package which is more recent
      than the current .PAC file for that package.

Works well for me (with some tweaking to the tools to maintain my invariants
automatically).  YMMV.

The only downside I see (beyond the necessity to tweak/replace some of the
tools) is that I don't have a versioned history of external resources such as
icon files and documentation.  As it happens I don't care much about their
history.

    -- chris