On 11 March 2010 03:51, Andreas Raab <andreas.raab at gmx.de> wrote:
> 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.
>

Andreas, i think that checking the repo before commit is brittle thing:
a) You not always comitting into same repository.
b) A remote repository is not always accessible, and so, one may
simply save a file into local filesystem, and then manually copy it to
the server.
c) a most insulting thing is, that when you clicking 'save', it trying
to connect to the net _before_ saving a file on local repository, and
throwing an exception into your face instead of doing a simplest
possible thing - just save it.


> Cheers,
>  - Andreas


-- 
Best regards,
Igor Stasenko AKA sig.