I think that the answer lies somewhere between "Internet TV" and "Cloud Computing" on the rising shoulder of the "Peak of Inflated Expectations" (Although I think that both of these have moved on somewhat rapidly in the past couple of years).
Nature of the Hype Cycle:
As I understand it, progression through the hype cycle is characterized by an evolving awareness about the pros and cons of a particular technology, rather than by any objective measure of "maturity" (whatever that means).
Before we have accumulated a sufficiently diverse set of experiences to build balanced (and independent) opinions, crowd dynamics (naturally) hold sway, with highly correlated opinions with little diversity, subtlety or depth of analysis.
This is as true in the "Trough of Disillusionment" as it is in the "Peak of Inflated Expectations"
If the community were to produce a wide and diverse range of different opinions, with in depth analysis about where and when it is appropriate to deploy DVCS and where and when it is not, then we can infer we are in the "Plateau of Productivity" (Or at least some way up the "Slope of Enlightenment").
If, on the other hand, the discourse is focussed on the superiority (or otherwise) of a technology without regard to the dips and folds of the competitive landscape upon which it stands, then we might infer that we are either on the "Peak of Inflated Expectations" or the "Trough of Disillusionment". We could even be in both phases at the same time, if the community is divided into camps by a flame war.
Evaluation of DVCS according to these criteria:
From the relatively shallow analysis that I have seen in the discourse so far, and the relative absence of negative commentary, I would estimate that we are currently climbing the "Peak of Inflated Expectations", with questions (such as this one) indicating that there are some who are preparing the slope down on the other side.
I think a strong indicator of the maturity of DVCS technology (from a corporate standpoint) will be when the debate shifts from asking simply "Why DVCS?" to "How can we best structure our workflow and processes around DVCS to maximise benefit to the organisation?".
From what I have seen, we are not all there yet. (Although some of our more sophisticated compatriots are leading the way)
The role of the Hype Cycle in decision making:
The "Hype Cycle" model is a model of behavioral bias, and it helps us understand our own mental state. If we can determine that a technology is hyped by others, then that may affect our own mental stance, and (at the risk of some double-think) we may need to compensate accordingly and force ourselves to behave rationally in choosing our selection criteria.
Needless to say, selection criteria choices are extremely context dependent.
Personally I would do (as a sort of brainstorming exercise) a short (15 minute) SWOT analysis of each option that you are considering, together with (seriously) a PEST analysis of the situation to ensure that you bring broader (non-technological) factors in your analysis.
SWOT for Distributed VCS
- Flexibility - more freedom to choose different workflows.
- Better performance over low-bandwidth/high-latency network connections - better for distributed teams & off-site workers.
- More sophisticated merge functionality, allowing you to branch more often. (I am not sure that this is a good thing).
- Source code is "backed up" on each developers machine. (pretty bogus, this one, as it might interfere with proper disaster recovery planning)
- Flexibility - Because we have more freedom to choose different workflows, we need to do additional work to define which workflow we are using, and to enforce it.
- Complexity & Conceptual Difficulty (especially for non-software-developer team members).
- Perhaps the flexibility can be utilized to engineer a workflow that is better suited to business needs?
- Perhaps we will spend so long re-engineering our workflow we will loose focus on our core product?
- It can be difficult to get some people to use even simple tools, especially if they do not believe that they are necessary or are otherwise not motivated.
SWOT for Centralized VCS
- Provides an in-band implicit communications channel for business organisation & process.
- Restricts possible workflows to a (in many cases reasonable) subset.
- Makes it easier to set up CI & other development automation tools.
- (SVN specific) Supports huge repositories.
- (SVN specific) Very stable, used by lots of big, conservative organisations.
- Politically more acceptable in a top-down command & control organization?
- Poor performance over low-bandwidth / high-latency connections, making it harder to use for distributed teams and off-site workers (especially if the repository gets big)
- Perhaps we can use the monolithic nature of the repository to help developers navigate the product and reuse each other's code more?
- If the project suddenly becomes hyper-important and we need to bring in additional developers working on other sites, can they effectively work with a SVN repository hosted (for them) off-site?
- If the set of developers grows so large that coordinating them becomes difficult, will the single centralized repository become a bottleneck? (Can we get around this any other way?)
Which VCS to use is dependent upon individual circumstance. For many of the situations in which I have worked, a DVCS with a centralized workflow would have done just fine, but I would have had to justify the time & effort to build out mechanism to support and enforce workflow, which would have been (still is) difficult.
Ultimately, I think that the discussion should center around the question: What workflow best suits our business? The best tool to use should follow naturally from the answer to that question.