[Seaside] monticello remote repositories

[Andreas Raab]

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

> -----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:45 AM
> To: seaside@lists.squeakfoundation.org
> Subject: Re: [Seaside] monticello remote repositories
> 
> 
> Andreas Raab wrote:
> > Julian,
> > 
> > 
> >>http://www.beta4.com/squeak/aubergines/docs/monticello.html
> > 
> > 
> > Reading through it and noticing in particular the parts on:
> > 
> > 	"Update: If the selected package is not yet loaded, load it into
> > your image. Otherwise, merge into the local image any 
> changes committed
> > to the repository since your last update. This will not remove any
> > changes you are in the process of making. If changes 
> committed to the
> > repository conflict with your local changes, a dialog will 
> ask you to
> > pick a version of the conflicting method."
> > 
> > and
> > 
> > 	"The UI (particularly for conflict resolution) is very
> > primitive."
> > 
> > I thought it would be _very_ worthwhile to put in a note 
> about "versions
> > of methods" (assuming that this hasn't been changed in 
> Monticello). I
> > don't know if you ever use this but I do all the time and what it
> > essentially means is that except in the case that you have 
> a conflict in
> > critical code that you are currently running you could actually just
> > file in the stuff from the server and then open up a 
> "message list" on
> > those methods that have changed and show the diffs to their 
> last (e.g.,
> > locally modified) version. In which case you got everything 
> you need for
> > conflict resolution.
> 
> Hmm... I may be misunderstanding, but it sounds to me like 
> you're saying 
> that a diff between your modified version and the newest version from 
> the server is all the information you need to resolve the 
> conflict yourself.
> 
> Now, while I agree this is better than nothing (probably better than 
> just ignoring the new version from the server), what you 
> really want to 
> do here is a 3-way merge.  Let's say you last updated to 
> revision 10 and 
> get a method #foo (we'll call this version of the method R1). 
>  Then you 
> make some modifications to #foo (we'll call that version of 
> the method 
> M).  Then later you try to update to revision 15, but someone 
> else has 
> modified #foo (we'll call this version of the method R2).
> 
> Now I'm pretty sure this can be automated in many cases by 
> looking for 
> non-conflicting changes to different parts of the parsed 
> method, but at 
> very least, the interface we really want is the ability to see the 3 
> versions of the method (R1, R2, and M) and the diffs between 
> R1-R2 and 
> between R1-M.  By looking at that information (all easily 
> obtained) you 
> can make an informed decision about what the result of the 
> merge can be.
> 
> > I haven't used Monticello myself but given the experience I have of
> > wading through lots of change sets and try to figure out 
> "where exactly
> > a particular method broke" I found the versions and the diffs to be
> > incredibly useful and I would guess that they'd probably 
> solve 95% of
> > the problems with conflicting methods in practice (the 
> remaining 5% are
> > those places where you _do_ update code that you've changed 
> locally and
> > that is running).
> 
> I actually haven't used Monticello much myself yet, either.  
> It's built 
> up of ideas that I've had a lot of input into but I didn't ending up 
> writing much of the end product.
> 
> The model that Monticello currently implements is pretty 
> similar to the 
> CVS model but I think it can be pretty easily adapted to 
> other models. 
> When I find time I'll play with it some more.  But in any case, the 
> 3-way merge is something we need to implement.  I should dig up some 
> details on the algorithm... it isn't difficult concepetually but it's 
> probably complex to implement.
> 
> Julian
> > 
> > Cheers,
> >   - Andreas
> > 
> > _______________________________________________
> > 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
>