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
|