Eek.  *don't* file in the last two methods in SourceFileReadOnlyCopy.1.cs as
they screw up version scanning during condensation.


On Wed, May 19, 2010 at 12:05 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

> Hi All,
>
>     I'm a bit late to this party but I just had cause to condense changes
> in an image but wanted to retain most version history.  By most I mean I
> want to retain the linear history (a method's direct ancestor versions), not
> the full history including reversions.  So if one has a set of stamps like
>  eem 7/7/2009 20:06 7 July 2009 8:06 pm
> eem 6/18/2009 19:21 18 June 2009 7:21 pm
>  eem 5/5/2009 12:16 5 May 2009 12:16 pm
> eem 6/18/2009 19:19 18 June 2009 7:19 pm
>  eem 6/18/2009 18:57 18 June 2009 6:57 pm
> eem 5/5/2009 12:16 5 May 2009 12:16 pm
>  eem 6/18/2009 18:17 18 June 2009 6:17 pm
> eem 6/18/2009 18:14 18 June 2009 6:14 pm
>  eem 6/18/2009 18:06 18 June 2009 6:06 pm
> eem 5/5/2009 12:16 5 May 2009 12:16 pm
>  eem 5/4/2009 19:19 4 May 2009 7:19 pm
> the direct ancestry is
> eem 7/7/2009 20:06 7 July 2009 8:06 pm
>  eem 6/18/2009 19:21 18 June 2009 7:21 pm
> eem 5/5/2009 12:16 5 May 2009 12:16 pm
>  eem 5/4/2009 19:19 4 May 2009 7:19 pm
>
> This probably isn't useful as the default condense changes mechanism but
> its probably useful to a few of you, so here it is.  The first change set
> provides shared read-only copies of the sources files for faster version
> scanning.  The second change set provides the code to extract the direct
> ancestry and a hack in
> ClassDescription>>fileOutChangedMessages:on:moveSource:toFile: to force use
> of ClassDescription>>printMethodChunkHistorically:on:moveSource:toFile: when
> condensing.  If y'all think this is generally useful we can make "condense
> preserving history" an option alongside condenseChanges, condenseSources et
> al.
>
> HTH
> Eliot
>
> On Wed, Mar 31, 2010 at 11:34 PM, Andreas Raab <andreas.raab at gmx.de>wrote:
>
>> Hi -
>>
>> I just posted the code condensing sources in 4.1. It looks like it works
>> fine; if anyone wants to try it (in a throwaway image please!) run it via:
>>
>>        Smalltalk appendChangesTo: 'mytest.sources'.
>>
>> This will copy the old sources, append the condensed changes and run the
>> image with the new sources file. Everything should continue to work as is,
>> but method histories should show both, the latest 4.1 version and the
>> original 4.0 version (but not the intermediates).
>>
>> Cheers,
>>  - Andreas
>>
>>
>>
>> On 3/29/2010 1:59 PM, Andreas Raab wrote:
>>
>>> Hi -
>>>
>>> I just wanted to float an idea that Eliot came up with over lunch. He
>>> pointed out that it would be good if we could preserve the method
>>> history from 4.0 but that it also would be good if we could ship with an
>>> empty changes file. Both of which can be achieved if we'd be condensing
>>> the changes file *to the end of* the sources file, i.e,
>>>
>>> SqueakV41.source = SqueakV4.sources + Squeak4.1.changes
>>>
>>> This has some advantages besides the empty changes file. It allows us to
>>> keep up with the intermediate stages during the RCs. In other words, for
>>> the next RC I can make a SqueakV41.sources and the image will be
>>> "compatible" with later versions of the sources file. In fact,
>>> SqueakV41.sources would be compatible with with SqueakV40.sources, too,
>>> so you could link the old sources file to the new one to save space if
>>> desired.
>>>
>>> What do people think? Sounds like a plan?
>>>
>>> Cheers,
>>> - Andreas
>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100519/75e64377/attachment.htm