Version Histories (was Whats Happening with 3.10. etc.)

Ralph Johnson johnson at cs.uiuc.edu
Thu Jan 11 10:37:38 UTC 2007


On 1/11/07, tim Rowledge <tim at rowledge.org> wrote:
> Here is my schema, such as it is thus far, for improving the source
> referencing. It's not complete. I need some suggestions for ways to
> tackle a few items.

The history of a software project is valuable, and should be
preserved.  But the changes file does not seem to me to be the right
way to do it.

First, most programmers doesn't really care about history back in the
90s.  The people who do care are very important people, so this is not
a reason for ignoring history, but it does indicate that perhaps it is
not necessary to duplicate history with every image.

Second, we are going to split the image into pieces.  In particular,
we plan to have a KernelImage that has no GUI to speak of; Morphic
will be loaded from Monticello.  Keeping the history of Morphic in the
changes file will be pretty wierd at this point.  And it will seem
wierd to have a 2 meg image with a 15 meg changes file.

So, I have an alternative idea.  I haven't looked into this much,
perhaps you can tell me why it won't work.  The idea is to change ONLY
the code to look at past versions of a method, nothing else.  I
imagine that this code looks back through the changes file and, at
some point, says "nothing there".  At that point, we'd change it to
look in the "history database".  I think that the only place that past
versions is used is in a few "version browsers", such as the
VersionsBrowser and the ClassCommentVersionsBrowser.  It seems like it
would be easier to fix them than to fix CompiledMethods.

Anyway, once these version browsers know how to look in a database for
history instead of in the changes file, we can compress the entire
changes file into the sources file, and our final release of 3.10
would have an empty changes file.  When people look at version
history, the version history tools would still look at the changes
file for the changes that they made, but would look in the history
database for older changes.  The current tools would all work the same
way that they do now, but the changes file would be a lot smaller.

What is wrong with this?

-Ralph



More information about the Squeak-dev mailing list