On 3/10/2010 8:44 PM, Igor Stasenko wrote:
> On 11 March 2010 05:29, Andreas Raab<andreas.raab at gmx.de>  wrote:
>> We simply have different working styles. None of the above applies to my
>> workflows. For example, I *do* commit into the same repostories practically
>> always (if I don't then it's because I'm doing an explicit merge and single
>> false positive really doesn't matter) and my remote repositories *are*
>> always accessible (if they aren't I call up our admin and give him an
>> earful) and since MC is going to commit it to the repository anyway, having
>> it contact it sooner rather than later makes absolutely no difference to me.
>
> You know, i had problems several times because i was assuming, that i
> always can access to remote repository and commit things right away.
> And then i lost the packages, lost the commit history because of that.

Fair enough. When that happens we'll fire our admin (just kidding :-)

Seriously, I just don't care about this any longer. I expect my network 
to be up, I expect my VPN to be up, I expect my repository to be up. 
Period. For work, we switched to Gemstone for precisely the reasons of 
stability and availability and I can only recommend that to anyone who 
really needs the repository to be up and running. For Squeak, I'm fine 
to save my image until squeaksource.com  or source.squeak.org is back up 
(but the latter has been markedly improving after we updated it to run 
on trunk).

>> I'm not saying you have to use this style, I'm saying it works for me and is
>> much more efficient than the alternatives. In particular checking a
>> repository after each commit is something that I just can't be bothered
>> with. Doing this kind of mechanical stuff is exactly what tools are for.
>>
>
> Its ok to check _after_ you successfully commit. But not before. See my point?

I see your point. I simply disagree with it. It's perfectly fine to 
check before commit.

Cheers,
   - Andreas