[ANN] Monticello Versioning
Colin Putney
cputney at wiresong.ca
Wed Jul 23 23:32:36 UTC 2003
On Wednesday, July 23, 2003, at 03:29 PM, Avi Bryant wrote:
>
> On Wed, 23 Jul 2003, Colin Putney wrote:
>
>> No, it's not the same problem.
>>
>> With a three-way merge, you can't produce an inconsistent snaphot. You
>> can produce a snapshot that doesn't work correctly - it may not pass
>> its tests, for example, but it will always represent a state of the
>> package that you could have created in the image and then saved as a
>> version.
>>
>> With the four-way merge scenario, it's possible to produce a snapshot
>> that won't even compile. That breaks an important invariant within
>> Monticello, and I don't think we want to allow that.
>
> I think you're overstating the problem. I can get almost the same
> effect
> by moving a superclass out of the package namespace (into an unrelated
> category) and then saving a version. It'll load fine in my image but
> not
> in anyone else's. Luckily, nothing actually *breaks*, it'll just warn
> you
> that the package has unmet dependencies when you try to load it. The
> same
> thing would happen during this merge - you would produce a new merged
> snapshot that would then fail when you tried to load it, and your image
> would be left unchanged.
Yeah, probably. It *isn't* a problem, as long as we don't let versions
be created with inconsistent snapshots. But the possibility of such a
snapshot is a wrinkle you don't get in three-way merging, and I do want
to set it apart from the general notion that merging versions can
produce code that doesn't work.
> Now when things would get nasty is if you ended up with a patch that
> both
> removes a class and adds a method or subclass to the same class,
> because
> the dependency checking isn't smart enough to catch that yet (basically
> because the additions happen before the removals). I'm pretty sure
> that a
> 4-way merge is no more likely to produce that than a 3-way merge is
> (that
> is, in both cases you would end up with a conflict during the merge,
> and
> you would only get the above situation if you made bad choices when
> resolving conflicts).
Yes. We can certainly do more in terms of dependency checking.
Colin
More information about the Squeak-dev
mailing list
|