[squeak-dev] Re: The Trunk: Monticello-ar.379.mcz

Andreas Raab andreas.raab at gmx.de
Thu Mar 11 01:51:28 UTC 2010


On 3/10/2010 5:11 PM, Colin Putney wrote:
>
> On 2010-03-10, at 2:24 AM, Bert Freudenberg wrote:
>
>> On 10.03.2010, at 05:06, Colin Putney wrote:
>>>
>>>
>>> On 2010-03-09, at 7:33 PM, Eliot Miranda wrote:
>>>
>>>> But I find knowing there's a newer version is /really/ useful.  It's all too easy to miss that someone else has updated your pet package with good stuff and plough on loosing their changes in the mists of time.  I vote for keeping the check-in.  It doesn't stop you form committing but has the huge advantage of knowing that a merge might be in your future.
>>>
>>> Why not just open the repository browser after you've committed? Any unmerged versions would be displayed in bold.
>>>
>>> Come to think of it, that would be more useful than opening the version inspector the way we do now.
>>>
>>> Colin
>>
>> This depends on the usage style I think. You can use Monticello in "distributed" style where there is no clear head, or "linear" style where the highest-numbered revision is significant. The Trunk's update mechanism uses the latter so I find the warning useful in that setting.
>
> No. It's always better to commit first and merge afterward. If you have a collaboration style where the "head" is an important concept, you just merge right after committing, rather than at "integration time."

It's interesting to see the different styles at work. For me, having the 
notifier makes the overall workflow much more efficient. Take trunk for 
example (our internal workflow is very similar): If you get a reminder 
that there's something "ahead" of your commit, you hit update and it's 
done in about ten seconds or so. Conflicts are rare so there mostly 
isn't anything else to do.

Contrast this with the alternative: It implies that for *every* commit 
you need to check the repository if there is a potential conflict (this 
is why I said "I'm too lazy" in the checkin comment). If there is, you 
need to select the unmerged version(s), merge them, write a change 
comment, save them back. Repeat that for every commit. After a while 
you're so tired out that you don't check and it goes okay, until you get 
really bitten. That's the point when you start wondering why MC can't 
tell you that there's stuff you need to merge. At least that's the way 
it worked for me :-)

BTW, like I said earlier, I'll be happy to make that a preference. 
Different people work differently, no need to slow you down with 
something that serves no purpose in your chosen workflow.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list