[Seaside] monticello remote repositories

Mon, 30 Dec 2002 14:26:14 -0500

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

> -----Original Message-----
> From: seaside-admin@lists.squeakfoundation.org 
> [mailto:seaside-admin@lists.squeakfoundation.org] On Behalf 
> Of Julian Fitzell
> Sent: Monday, December 30, 2002 1:41 PM
> To: seaside@lists.squeakfoundation.org
> Subject: Re: [Seaside] monticello remote repositories
> 
> 
> Hmm... any thoughts or advice having implemented it once already?
> 
> Julian
> 
> Stephen Pair wrote:
> > For the ObjectStudio team edition, I implemented a 3-way 
> merge tool, 
> > and I can say from experience that having such a tool is 
> quite nice.  
> > A 3-way merge in Smalltalk isn't quite as critical as in other file 
> > based languages, but it is useful.
> > 
> > In the example that Julian gives below, a three way tool takes the 
> > guess work out of the merge.  Also, showing the diffs between a 
> > version and a base version is much more meaningful than showing the 
> > diffs between to diverging versions because it shows the 
> exact changes 
> > that were made by a developer; which makes it much easier 
> to see what 
> > those changes as whole were intended to accomplish.
> > 
> > - Stephen
> > 
> > 
> >>-----Original Message-----
> >>From: seaside-admin@lists.squeakfoundation.org
> >>[mailto:seaside-admin@lists.squeakfoundation.org] On Behalf 
> >>Of Julian Fitzell
> >>Sent: Sunday, December 29, 2002 9:40 PM
> >>To: seaside@lists.squeakfoundation.org
> >>Subject: Re: [Seaside] monticello remote repositories
> >>
> >>
> >>Andreas,
> >>
> >>I agree that 3-way merging is probably less useful in Squeak than in
> >>other languages since methods do often end up being very 
> >>short.  I'm not 
> >>convinced though, that you couldn't to 3-way merge at a finer 
> >>granularity than line-by-line.  I think by analyzing the 
> >>parsed method 
> >>you ought to be able to tell, for example that if you had:
> >>
> >>foo
> >>   ^ self bar
> >>
> >>And the two modified versions:
> >>
> >>foo
> >>   ^ self bar asString
> >>
> >>and
> >>
> >>foo
> >>   ^ someBool ifTrue: [self bar] ifFalse: [self baz]
> >>
> >>You might well be able to merge both of these changes into:
> >>
> >>foo
> >>   ^ someBool ifTrue: [self bar asString] ifFalse: [self baz]
> >>
> >>
> >>I haven't given this too much thought, nor have I even 
> looked in much
> >>detail at the parsed structure of the method, so I way well be 
> >>completely wrong.  But it's still an interesting idea! :)
> >>
> >>But I certainly concede that having automated 3-way merge is
> >>by no means 
> >>a necessity and probably of less need in Squeak code than in 
> >>C code for 
> >>example.
> >>
> >>I still don't quite see how a diff between my modified
> >>version and the 
> >>version on the server is helpful, though.  It seems to me 
> >>that that diff 
> >>would contain both the changes made between the two 
> >>repository versions 
> >>and the *reverse* (ie removal) of the changes made in your 
> local copy.
> >>
> >>This is where I was wondering if I was misunderstanding you 
> or if I'm
> >>just not seeing the benefit.  I certianly think that long before 
> >>automated merging is done, being able to see all 3 versions 
> and their 
> >>respective diffs would be useful.
> >>
> >>Julian
> >>
> >>Andreas Raab wrote:
> >>
> >>>Julian,
> >>>
> >>>I think that three way merging/diffing is probably overrated in the
> >>>praxis of Squeak (or any other Smalltalk) coding. Three way 
> >>>merges/diffs are mostly needed if the granularity of the 
> >>
> >>code you are
> >>
> >>>looking at is very large (e.g., at the file level or at very long
> >>>method level). For most portions of code I have ever looked at in 
> >>>Squeak (and believe me it's been lots ;-) I have hardly 
> ever needed 
> >>>the three-way comparison. Mostly because if you see a diff against 
> >>>*your* code (e.g., code that you have modified) and use the source 
> >>>code manager in a reasonable way (by which I mean to update 
> >>
> >>every now
> >>
> >>>and then and not every other year) you can usually remember
> >>
> >>what the
> >>
> >>>point of a particular change was and see if that update
> >>
> >>addresses the
> >>
> >>>problem or obsoletes it or relates to it at all. From my personal
> >>>experiences that's mostly what you need.
> >>>
> >>>Most cases I remember where I wanted three way diffs were
> >>
> >>exactly what
> >>
> >>>I described above - either "large methods" (like Interpreter
> >>>class>>initializePrimitiveTable) or places where I wanted 
> to compare
> >>>changes on a "file level" (e.g., seeing all the changes
> >>
> >>being done in
> >>
> >>>a particular class). Yet, I would still argue that these
> >>
> >>fall into the
> >>
> >>>5% category ;-)
> >>>
> >>>So I'm not claiming that you never need a three way
> >>
> >>merge/comparison.
> >>
> >>>But I think you could cover lots and lots of grounds by just using
> >>>what's already there.
> >>>
> >>>Cheers,
> >>>  - Andreas
> >>
> >>
> >>
> >>--
> >>julian@beta4.com
> >>Beta4 Productions (http://www.beta4.com)
> >>
> >>_______________________________________________
> >>Seaside mailing list
> >>Seaside@lists.squeakfoundation.org
> >>http://lists.squeakfoundation.org/listinfo/seaside
> >>
> > 
> > 
> > _______________________________________________
> > Seaside mailing list
> > Seaside@lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/listinfo/seaside
> 
> 
> -- 
> julian@beta4.com
> Beta4 Productions (http://www.beta4.com)
> 
> _______________________________________________
> Seaside mailing list
> Seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
> 