[Seaside] monticello remote repositories

[Stephen Pair]

> Right, that actually sounds pretty similar to what I have in my head.
> 
> I presume you did the actual merge by looking at the parsed method 
> trees?  

No...that wouldn't handle things that don't impact the parse tree (i.e.
comments).

> Colin I were talking last night about different kinds of 
> conflicts besides just changing the same method.  For example:
>
> - an instvar is renamed in one versions and another version has a new 
> version of a method that uses the old name
> - one version removes an instvar that the other requires
> - one version adds an instvar and another version adds a temporary 
> variable with the same name
> 
> These are all things that we could detect and offer 
> sugestions to fix or 
> possibly (in the first case, for example) even fix 
> automatically during 
> the merge.  It's just a matter of how complicated we want to get.
> 
> Did you detect any of these kind of things?  

No, but they do sound like useful things to detect.  I wouldn't go nuts
trying to put them in a first version though.

> Am I correct in reading 
> that you immediately applied the auto-merged version to the image (to 
> make it active) and then provided it for modification by the user?

Yes...sort of.  It was modifyable, but it wasn't necessarily active.
Whether or not a package was active was independent of whether or not
you could edit the code in it (we did compile the code however).  The
normal case was to make the merged version active, but the developer
could opt out of that and edit it without it being active.  But, there
was no "auto-merge"...the developer would select one of the two
differing versions to serve as the basis for the merged version (in
fact, one of the two differing versions could even be used as the target
for the merge if it was an open edition (in Envy terms)).  Read more
about this below...
 
> Thinking through that in my head last night it seemed like 
> there would 
> be a problem for example, if two versions added a new method with the 
> same name.  It is likely that that is a conflict that cannot 
> be resolved 
> by auto-merge, but if you don't resolve that conflict first, 
> you cannot 
> apply any non-conflicting changes that rely on the existance of that 
> method.  I very quickly came up with the following order 
> (though it is 
> surely incomplete):
> 
> 1. apply instvar changes
> 2. apply non-conflicting method insertions
> 3. resolve double method insertion conflicts
> 4. attempt to apply non-conflicting method modifications 
> (prompt if they 
> don't apply)
> 5. resolve conflicting method modifications
> 
> Assuming we have a broad concept of "conflict" #4 should be straight 
> forward because we would already have detected methods that had 
> conflicts with instvars and either resolved them 
> automatically or left 
> them for conflict resolution later.
> 
> Colin looked at the Compiler and seemed to think we could get it to 
> parse the method and return errors without actually installing the 
> methods so we may be able to resolve all the conflicts in the right 
> order before applying anything to the image...
>
> Anyway, I've rambled enough. :)  That's what we've been talking about.
> 
> Julin

To eliminate a lot of this complexity, a merged version was initially
just based off of one of the differing versions.  So, in the Squeak
case, if you did that it would allow you to make the merged version
active and editable (since it would initially be identical to one of the
two differing versions).  There would be no need to do any sort of
auto-merge.  In fact, I'd say you'd want to avoid any sort of attempt at
auto-merging because in the end, you're just guessing that the result is
what the developer really wants.  Instead, focus on making it easy for
the developer to apply all of the things that you might apply in the
auto-merge.  For example, if the developer wants to do the 5 things you
list above, make it take like 5 clicks to do it rather than guess that
those five things are what they want.  

We asked the developer which version they wanted to use for seeding the
merged version...if you are using my VersionNumber package, you could
simply always select the branch that is closest to the trunk.

- Stephen