Strategies for push/merge problem?

[Douglas Philips]

On or about 2008 Jul 28, at 7:34 AM, Sean Russell indited:
> The difference between DVCSes and centralized ones is where the  
> bottlenecks
> are.  In centralized ones, it is a machine; in DVCSes, it is a  
> human.  I
> argue that people are much worse to have as bottlenecks: they're  
> much slower.
> ...
> What you're arguing
> for is to have a human do something that a machine could easily do  
> -- apply a
> patch that can't conflict, because it has already been merged.  It is
> inherently slower.

http://www.selenic.com/pipermail/mercurial/2008-July/020218.html


> Having a central location can be important.  It ensures an  
> authoritative
> source for people pulling information, which is absolutely critical  
> in a
> corporate environment where accountability is a concern.

Accountability when no human is involved? Odd use that term, to say  
the least.
"But, but, it can't be my fault, all the tests passed before I pushed!"
The pull model means that any test results can be exactly reproduced,
but with the push model you can't be sure that someone else hasn't
pushed conflicting changes to another part of the tree at the same time.
So no matter how much you test in advance, you end up with a tree
that has never been tested. And yes, with automerging on the server
you can end up that way with Hg too. Doesn't seem like accountability
to me. At least with Hg/DVCSs there is a record to show that a merge
happened, and a way to recover. With CVS, merges happen without any
record... how does that lack of record(s) provide accountability?
And how does it assist recovery?

--Doug