[squeak-dev] Re: The Trunk: Monticello-ar.379.mcz
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.
>> 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.
More information about the Squeak-dev