[squeak-dev] Re: [Webteam] Suggestion for Squeak Website

Hello Michael,
>
> I'd be interested in hearing your thoughts on this approach.
>
> Cheers,
> Michael
>  
I have been using Bazaar to version control my images, I am just getting
to grips with it, and I think it is fantastic, better than mercurial for
managing squeak images. So I have set up a server that I can use, and
make public at some point.

My typical workflow involves, downloading the version I want, unzipping,
copying, moving the version into my "Originals" folder, applying LPF,
copying that moving that into my "LPF" folder, and then copy that to a
working directory in which I start to load the packages that I need.

In looking at the Bazaar user manual, it allows some interesting ways of
organizing a reporistory of versions/branches. Here is a sample of my
current repository structure.

/squeak/3.10/.bzr
/squeak/3.10/LPF/.bzr
/squeak/3.10/LPF/pr_tools/.bzr
/squeak/3.7/.bzr
/squeak/3.8/.bzr
/squeak/3.8.1/.bzr
/squeak/3.9.1/.bzr
/squeak/3.9.1/LPF/.bzr

The directory /squeak/3.10/.bzr is a repository for the base version,
which contains within it, the repository for the LPF image that was
derived from 3.10  /Squeak/3.10/LPF/.bzr , which in turn contains a
repository of my "pr_tools" working image, which was derived from the
LPF version.

A user can obtain a base 3.10 release, specifying a revision number or
tag if need be,  via:

bzr checkout sftp://squeak.warwick.st/squeak/3.10 myworkingdirectory
--lightweight

to obtain the LPF derivative:

bzr checkout sftp://squeak.warwick.st/squeak/3.10/LPF myworkingdirectory
--lightweight

to obtain a personal working branch for a new project based upon 3.10/LPF:

bzr branch sftp://squeak.warwick.st/squeak/3.10/LPF mynewproject
--lightweight

to publish a the new project back to the shared repository:

cd mynewpoject
bzr push sftp://squeak.warwick.st/squeak/3.10/LPF/mynewproject

Although I am not writing a book, I am wanting to simplify, a) the
learning process, and b) the collaboration process. Although it is
getting easier the process of enabling others to learn and come on board
is still an uphill one.

So my plan is to adjust my day to day working to use a number of "Public
Images". I will have a single image as my working environment for 5 or 6
tools, and publish that as a version controlled deliverable.  This
deliverable will have the test environment for each package ready to
run, and the documentation that is written can be version managed
alongside or in some cases in the image itself.

If this works, I can ensure that a properly configured image with of all
of these tools is available for anyone to browse and try out. When it
comes to collaboration on any one tool, there is a clearly defined and
very easily obtainable test-bed for any new innovations.

I am hoping that this deliverable, version managed in a public
repository, will help me to address some of my own weaknesses. I often
find myself publishing packages which unwittingly break things. This is
fine, IFF you can adequately inform potential users, as to which
versions are working correctly and which versions are still pre-release,
which tests pass and which fail. Our current tools (mcz/universes) do
not provide that part of the feedback loop and so it is often very
difficult to inform our users exactly which combination of bits works as
intended.... So my solution is to adopt these version controlled
"reference images".

With such a hierarchical version controlled server in place, it becomes
much simpler to tell a user exactly which image they need  for a
particular tutorial. Furthermore, the documentation could be version
managed together with an image as a coherent whole.

 just my 2p

Keith