Colin Putney wrote:
> 
> On Wednesday, July 23, 2003, at 03:29  PM, Avi Bryant wrote:
>> 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 

I thought you could only create a version from the current state of your 
image?  Oh, no... you're creating a new version first and then applying 
that version to the image?  Anyway, clearly you shouldn't be able to 
commit (or create or whatever we're calling it) a version that can't 
actually exist in an image.

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

Hmm... so your argument is that merges that can file in and then 
silently not work are ok, but merges that are obviously broken and can't 
be filed in because you screwed up are not?  ;)  I think the three-way 
case is worse...

<duck-and-run />

(And yes, I realize that the four-way merge offers the possibility of 
both sets of problems).

Seriously though, I think we can probably let the thread die now.  The 
disagreement of whether we actually *like* 4-way merges is kind of 
irrelevant as long as we agree that there are uses of it that people 
will want, and that the feature should exist.

Julian