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

Avi Bryant avi at beta4.com
Wed Jul 14 00:44:41 UTC 2004


On Jul 13, 2004, at 3:42 AM, danielv at tx.technion.ac.il wrote:

> If the right way to do this is to have a version for every patch I
> filein, then it would be a good thing to MC to detect such system 
> operations
> and version before and after them automatically. I know the lack of 
> this
> feature was a great annoyance with change sets.

That makes sense, as a transitional measure (for however long people 
still submit change sets more than they do versions).  It would be part 
of a set of reviewer-friendly extensions to MC.  I would imagine the 
full process would be this:

- you start at a baseline version, probably a recent release
- you choose a changeset to review, which gets filed in.  A version is 
automatically saved, recording the preamble comment from the changeset.
- you try out the changes, possibly making minor modifications along 
the way.  When you're done, you provide a set of review notes.  A new 
version is made with your modifications and these notes.
- the system is then reverted back to the baseline release, before the 
next changeset comes in

>> But no, there's no easy way
>> to apply the diff between two versions to an unrelated third version.
> AFAIU, they should not be unrelated versions - MCing people will be
> synching with Dougs repository quite often. Maybe I'm missing
> something?

No, I was just misunderstanding what you wanted.

> I think we should whatever is possible to make sure that merges do not
> become more messy, since we'll be doing lots of them. For example if we
> want to handle the file in of other formats as mentioned above, and
> suppose to people filein the same code separately, it would be nice if
> MC knew the common ancestry (say, by using a content hash on the file).

Hm.  So basically generate a fictional ancestor version for the 
changeset, giving it a UUID based on the hash of the file.  That's an 
interesting idea.  I'll have to think through the implications.

Avi




More information about the Squeak-dev mailing list