[Seaside] monticello remote repositories

[Julian Fitzell]

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

Stephen Pair wrote:
> Well, the ObjectStudio (OS) merge tool was a bit more complicated by the
> fact that we had a package hierarchy that could be nested to arbitrarily
> deep levels.  So, we needed a three way merge that would show differing
> sub-packages (and differing versions of sub-packages)...so that doesn't
> really apply here.
> 
> Beyond that, there's basically nothing to it.  We showed the common base
> version in a pane in the lower left, the two differing versions in two
> upper panes, and the merge version in the lower right pane.  Syntax
> highlighting would show the diffs in the two differing versions as
> compared with the common base version.
> 
> One thing I would change is that we would open different windows for
> each class that we were merging in a given package.  I would probably
> re-work that such that the merge of a package could all be handled in a
> single window.  Maybe a layout like the following would be good:
> 
> [ ][ ]
> [    ]
> [ ][ ]
> [    ] 
> 
> The top left pane shows a selection list of the differing classes, the
> top-right pane shows a selection list of the differing methods for the
> selected class (there would need to be a class/instance side selection
> somewhere).  The next pane down (line 2) would show the common base
> version of the selected item (which could be a class definition).  The
> two panes on line 3 would show the two differing versions with syntax
> highlighting showing the diffs with the common base version.  And, the
> bottom pane would show the merged version (which is editable of course
> and would probably need to be the active version in the image).
> 
> It would look a lot like a normal class browser minus the class
> categories and with the contents pane replaced with four separate panes
> enabling the three way merge.
> 
> You might even want to show all classes/methods that form the union of
> the two differing packages and highlight (in red or something) the
> classes and methods that are different in the two versions of the
> package.
> 
> We also showed the version name of all four versions that were involved
> just above each pane.  And we allowed merging *into* one of the two
> differing versions (if that version was an open version...which would
> not be applicable here).  We also had a button for each of the two
> differing versions and the common base version that would copy the
> contents to the merge version...but these are minor things.  
> 
> - Stephen
> 


-- 
julian@beta4.com
Beta4 Productions (http://www.beta4.com)