[Seaside] monticello remote repositories

[Julian Fitzell]

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)