> What is wrong with this?

Mostly it doesn't address the real issue and that's the limitation of 
the sources and changes file to 32MB each. That we can preserve the 
history by having a larger changes file is nice but not the primary goal 
as far as I am concerned.

Cheers,
   - Andreas

Ralph Johnson wrote:
> 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
> 
>