[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