Going for the Full Monti (Re: How to improve Squeak)

Avi Bryant avi at beta4.com
Tue Jul 13 02:25:22 UTC 2004


On Jul 12, 2004, at 2:28 AM, danielv at tx.technion.ac.il wrote:

> I think to replace the BFAV-centric process, MC needs to deal with some
> of the same, and some new concepts:
> 1. Instead of global "approvers", MC should let each user have a list 
> of
> "repos I monitor".

Doesn't it already?  Though I admit that "monitor" needs to be fleshed 
out: what I want is for it to automatically download new versions it 
finds in those repositories to the cache, and inform you of them - I'm 
picturing repositories being treated something like RSS feeds.

> 2. In addition to existing concepts, we need "patch" or "change", which
> aggregates some of the stuff an update does -
> a. Set of specific changes to a package (or a few?)
> b. Documentation of the change (as a change, besides code comments and
> so forth)
> People should be able to look at the list of patches in someones
> repository, not just the code diffs compared to his version. People
> should be able to take/reject/remove specific patches.

You can already look at the diffs between two arbitrary versions 
(though I admit the UI could make this more obvious).  And there are 
already commit logs for each change you make (and a given commit should 
really only encompass one or two changes).  But no, there's no easy way 
to apply the diff between two versions to an unrelated third version.  
The problem is that this has unspecified ancestry semantics: in what 
way does it affect future merges?  Should it not change the ancestry of 
your image at all, and just be as if you had independently made those 
same changes?  If that became a common practice, we'd make automatic 
merges much messier down the line.

Avi




More information about the Squeak-dev mailing list