[ANN] Monticello Versioning

Avi Bryant avi at beta4.com
Wed Jul 23 22:29:36 UTC 2003


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.

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).

Avi



More information about the Squeak-dev mailing list