Re: Two More Very General Consulting Question
On Fri, 9 Dec 2011, Andreas Leitgeb wrote:
I can imagine managers to be more afraid of longer sync-intervals,
resulting from the DVCS-philosophy, than of not seeing all devels'
The DVCS philosophy does not result in longer intervals between sharing
work with your colleagues (what i assume you mean by "sync-intervals").
Both centralised and distributed VCS makes it easy to share work with your
colleagues. You can do it as often or as seldom as you choose, or your
process dictates. The choice of centralised or distributed VCS has *no*
bearing on it.
I have come across this belief before. I honestly don't know where people
get it from.
Sooner or later I'll succeed in getting a client organization
interested, and interested for the right reasons. But it hasn't
It would have to be a client whose devels are working remote, and where
the benefits of piling up some work before a sync outweighs the higher
risk of conflicts happening.
No, as i explained, DVCS has benefits even in a conventionally-organised
1. History is super-important in these organizations. It is how you
I do understand this motivation. The "scapegoat" is typically the one
who is in the best position to fix a problem, so identifying him without
having to ask everyone is worth as much time as by what the scapegoat
will be able to fix it more efficiently than anyone else on the project.
DVCS is capable of recording history just as precisely as centralised VCS.
Indeed, because you can have multiple local commits in between pushes, it
can record *more* details about history.
DVCSs also give you tools to erase and rewrite history, but it is your
choice whether you use them or not. If you care about history, don't use
Work alone does not suffice: the efforts must be intelligent. -- Charles