[Seaside] monticello remote repositories

[Julian Fitzell]

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)