RFD - Envy-like MC repository

Colin Putney cputney at wiresong.ca
Fri Nov 4 12:36:15 UTC 2005


On Nov 4, 2005, at 4:24 AM, Cees De Groot wrote:

> Indeed. My current spike logs MCMethod/ClassDefinitions and groups
> them together under versions. Still needs work, though, for me to be
> able to reconstruct full snapshots :)

Any thoughts, yet, on how you'll handle ancestry? Seems like you've  
got a few options:

	- have each version keep it's own ancestry tree, the way "normal" MC  
does
	- intern the VersionInfo instances into a single ancestry graph, and  
reconstruct each
	  version's ancestry on the fly, similar to snapshots
	- store ancestry in a different way, and use a different merge  
algorithm

> Well... there are serious space and performance problems with
> Monticello. And other issues - I refer to someone here on the list
> having to manually clean the comment history of a package because it
> contained proprietary information.
>
> And a feature I sorely miss when compared to ENVY and also StORE is
> the ability to query the database. In VW, I often find myself going
> back to the method versions logged in StORE, etcetera.

Yes, these are definitely shortcomings of the current system. Slice  
takes the same approach you're trying here: break these monolithic  
versions we've got into smaller, independent data-structures, so we  
don't have nearly so much redundancy.

This gives saves us space, because repository size now grows in  
proportion to the amount of change in the packages is contains,  
rather than the number of versions. It also increases speed in the  
common case, since we no longer have to deal with the full contents  
of a snapshot when only a few methods have changed. This will be  
especially important during merges. And finally, having definitions  
be independently addressable gives us a way to reconstruct the  
history of single definitions without having to decompress, parse,  
and scan every version in the respository like we'd have to do in MC1.

It'll be interesting to see where this goes.

Colin



More information about the Squeak-dev mailing list