>> >> I don't know whether its possible to generate a .sources file that
>> >> would contain full history,
>> >
>> >
>> > _yes it is_.  The only issue in preserving history is in pruning
>> > branches.
>> > There is no point preserving versions that are not ancestors of current
>> > versions.  And that's an easy process.  I have code that does this and
>> > Camillo just rewrote source condensing for Pharo and claims its much
>> > more
>> > comprehensible, so taking his code and getting it to preserve history
>> > while
>> > pruning could be another route.
>>
>> How does your or Camillo's code work?  How could it possibly know what
>> version of, say, Dictionary>>#at:put: was released to official Squeak
>> 2.8?  Are you parsing into some cold 2.8 image file from a 4.5 image?
>
>
> The code merely collects all available versions of each method, prunes the
> versions which have no descendents and writes all these methods to the
> sources file.  [I don't know how Camillo;s code works].  So this won't
> magically retrieve older versions, but it *will* preserve the history we
> have since the writing of the 4.1 sources file.

Something I'm still trying to understand; what are the ones with "no
descendents"?  Wouldn't that just be the most-recent version?  Ah, you
mean all "the duplicates"..?

>> Even if you could identify all the CM's you still don't have the
>> source for them.  You'd have to then go looking into the cold image
>> file, identify which .sources file its using, find the source-pointer
>> for that method, THEN go into that sources file to extract it..
>
>
> That's not what it does.  What it does is condense preserving available
> history.  What we have no is condense, losing all available history.  As we
> accumulate more history so preserving extant history becomes more and more
> valuable, no?
>
>> I just don't believe you or Camillo are attempting something this
>> crazy -- hell just setting up all the images and sources would be a
>> major pain.  But I see no other way to accomplish what Hannes was
>> referring to as "full history".  Tell me how it works, show me the
>> code and how to use it, else I call bull-shit.  ;)
>
>
> But that's also quite possible and not that hard either.  A CHange List is a
> tool which can accomplish most of this.  It is a few days work.  But as I
> say, we can much more easily condense while preserving extant history.  Am I
> clearer now?

Not really.  But, I, for one, am for keeping all history (sans
duplicates).  I simply thought there was movement in the community to
want to use #condenseSources for deployment with no preservation of
anything.  Anyone concerned about size can easily condense their own
sources, but us who like full history cannot get that back easily if
we deploy condensedSources.  So, I like your idea better.

Should your code be run at the beginning of release cycle or the end?