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
|