[Help-smalltalk] Using version control locally with the GST source tree

[Paul D. Fernhout]

I justed want to mention in detail this neat idea related to using GST 
under local version control.

I had put the latest version of GST into a local Subversion (SVN) 
repository, which I am accessing under Eclipse using the Subclipse plugin. 
I did this mainly because I intended to make some local changes to 
experiment with it, however, I am already finding this to be very useful 
for other reasons, which I would like to share. What I have to say would 
probably apply to almost any version control system.

After doing a configure and make from the baseline 2.3 GST release, I 
could use SVN to easily tell me what had changed or added from the make (a 
lot!). It was interesting to be able to easily study in detail what the 
GST system (in the sense of being a big tree of files as an extended 
application) had done to itself after the make command. Then I could check 
in the results there to establish a new baseline. So I did that.

Unexpectedly, this new baseline checkin came in handy a few minutes later.

Next, I did a
  gst -qK blox/Run.st
which gave me a funny result (an error message, but don't worry, Paolo, as 
you will see, it was an issue on my end).

Then I did a

 gst -qK Load.st -a Browser Blox Compiler

from the manual (which is supposed to write out an image file):

  http://www.gnu.org/software/smalltalk/gst-manual/gst_17.html#SEC23

And SVN told me nothing had changed. So, SVN here was indirectly telling 
me something went wrong. Nice! Obviously, I could have looked at file 
dates and such, but I would have had to be sure what the files name was 
supposed to be and where it was supposed to be written in any of lots of 
subdirectories.

It took a while before I looked more carefully at the results of that 
command and saw a permission error writing to  a file, and then I saw the 
process was referencing files in "/usr/local/share/smalltalk", and then I 
realized already had an older GST installed as a Debian package. The plain 
gst command should not have worked at all, of course. Only "./gst" should 
have worked. Silly me to not notice.

So I uninstalled the package with apt-get, and when testing this to get 
the error I should have got the first time, I found surprisingly that gst 
was *still* in "/usr/local/bin/gst". Not sure why, so I removed it 
manually. Then I got the appropriate error of gst not found. I've tried 
gst on and off for years, so might have been some configuration issue left 
over from way back.

So now I run
  ./gst -qK Load.st -a Browser Blox Compiler
from the top level directory, and then SVN now tells me the image file 
there has changed (and only that has changed).  Yeah!

Now I can continue to explore GST (including perhaps major surgery related 
to a possible Java port), and I now know I can easily revert back to known 
states of the entire system -- even all the way back to not having done a 
make.

I wanted to mention this idea for a couple of reasons.

One is because it shows the power of version control even when you are 
just messing around with a complex system which is not your own code. You 
can see what the system is doing to itself -- and how it is changing in 
response to your commands. Finding out what changed is easy when the 
system is small, but once it is large, this gets hard. And when you make 
more than one change, this is harder still, as you are compounding 
changes. And this also shows, in this case, the advantage of GST being a 
series of files -- so you can easily use these tools like SVN on it to see 
how it changes over time. (Obviously, other Smalltalk have other tools for 
looking at changes to them, like changelogs or tools like ENVY which have 
their own strengths or weaknesses). I'd definitely recommend trying this 
if you have a local SVN repository around and you want to explore some new 
complex package (GST or otherwise). In one way, I am actually using SVN to 
give me a sort of coherent "image" like I am used to from other 
Smalltalks. Only in some ways this repository is more powerful -- sort of 
like closer to what ENVY allowed me to do in terms of looking at changes 
to the system in various packages, and allowing various hierarchical 
branches which can be saved as configurations, later loaded as entire sets 
of changes, or looked at side by side for differences.

Obviously if you think of yourself as a "developer" of a variant of GST, 
then putting all of GST under version control makes sense. But, the novel 
part here is the value of putting GST under version control for yourself 
when you only think of yourself just as a "user" or "average programmer" 
making an application with it. Of course, Smalltalk has always blurred 
that line. :-)

And perhaps this all may sound tame, since obviously it makes sense for 
any developer to put their *own* application under version control 
somehow, and once GST is working locally as expected, who cares about how 
GST binary files and configuration files change?

But, here is the other reasons: with Smalltalk, the spirit of the language 
(especially under a free license with source code) really encourages all 
sorts of minor changes here and there as needed. And as much as I disagree 
with the notion of random changes in various parts of the system from a 
maintainability standpoint (and so I avoid making them), I have started to 
wonder if a person like Dan Ingalls (in terms of Squeak's evolution) is 
right in their desire to change various core bits of the image as they 
make their applications (obviously someone like Dan is also going to have 
a sense of ownership of the Smalltalk image few others may never have in 
any case. :-) Still, I think it might make the most sense if one then 
confined oneself to having just one major application per customized image 
(or GST file tree); that might ultimately be easier to maintain rather 
than having lots of applications per common image which an entire 
community was messing with, which has been a big set of headaches for the 
Squeak community leading to "bit rot" as applications that used to work 
stop working. Now that disk space is so cheap, and the memory for a good 
VM is not that large (and some later VMs even share memory better across 
VM instances), then with good version control tools, why not have an 
entire customized Smalltalk system embedded along with each major 
application (web browser, simulation, email client, graphics tool, and so 
on)? I know, issues come up with the base system you would like to fix 
everywhere at once -- but in general, I would expect that the kind of 
changes most people would make to their base classes (adding test methods, 
or convenience methods, and such) would rarely collide with the kind of 
changes needed for portability or performance improvements, and so would 
be easy to merge.

I think the merging headaches related to GST upgrades might be less than 
those of trying to get a large and diverse community to agree on a 
standard set of base classes over time. At the very least, you'd know any 
working application would still be working wherever it used to until you 
tried to merge in new code specifically into that application's image or 
file tree. You could always be free to use newer GST versions with newer 
projects or just upgrade any of your projects that were easy to upgrade. 
And then testing could perhaps be managed more modularly too (on a "per 
major application upgrade" basis versus a "per major image change" basis, 
which often seems to lead to surprising failures among previously working 
applications). Also, free of the fear of changes causing failures in 
existing major applications built on that platform, mainline Smalltalk 
platform developers then might feel free to innovate more and make more 
radical changes with the core system (should that make sense). Of course 
to make all that work smoothly, one needs to have Smalltalk applications 
that can easily talk to each other through sockets, files, shared memory, 
serialized objects, or other means (and supporting other standards) than 
sharing references to live objects in a common VM memory pool. Yes, this 
is another set of standards and compatibility to worry about, but those 
communication standards seem to change more slowly and in more controlled 
ways than Smalltalk images, and using them is a common part of the 
Unix-derived experience. :-)

This approach is kind of like a variant on Paul Graham's idea of 
"bottom-up" Lisp programming. He writes:
  http://www.paulgraham.com/progbot.html
"Experienced Lisp programmers divide up their programs differently. As 
well as top-down design, they follow a principle which could be called 
bottom-up design-- changing the language to suit the problem. In Lisp, you 
don't just write your program down toward the language, you also build the 
language up toward your program. As you're writing a program you may think 
"I wish Lisp had such-and-such an operator." So you go and write it. 
Afterward you realize that using the new operator would simplify the 
design of another part of the program, and so on. Language and program 
evolve together. Like the border between two warring states, the boundary 
between language and program is drawn and redrawn, until eventually it 
comes to rest along the mountains and rivers, the natural frontiers of 
your problem. In the end your program will look as if the language had 
been designed for it. And when language and program fit one another well, 
you end up with code which is clear, small, and efficient."

So, a private copy of GST in SVN makes this meet-in-the-middle combination 
of top-down combined with bottom-up programming more feasible to think 
about and maintain in Smalltalk. SVN helps you see how you changed 
something from a baseline, and can also help you reintegrate "vendor 
branches"
  http://svnbook.red-bean.com/en/1.1/ch07s05.html
like new versions of GST back into a customized line of development.
So, it makes more feasible the idea of developing one application per 
customized version of GST (especially if you add in a notion like a 
variant for Java and the JVM that might make it possible to build one 
"jar" file that could run on all supported platforms, and hopefully be 
forward compatible with improved JVM versions and libraries. :-).

Anyway, to sum up, I think I just bumbled into a "powerful idea" somehow, 
of using version control on a new complex application like GST 2.3 just to 
monitor what it does. :-) Probably obvious to people here, but new and 
surprising to me. And there is something even more powerful -- 
"meet-in-the-middle" programming :-) -- that GST's unusual file-based 
architecture (for a Smalltalk) makes even more possible using conventional 
version control tools (SVN or whatever, I have not tried GNU Arch yet but 
I assume it can do the same thing?), and thus could open up a new style of 
programming for the free Smalltalk community, or, rather, perhaps make an 
old style of Smalltalk programming more feasible on a networked community 
basis. Now the GST community may already have other ideas for doing this, 
so if there is some other common way of doing this with GST, I'd love to 
hear it.

--Paul Fernhout