A VersionControlSystem that uses inter-repository replication as the mechanism for collaboration. Each participant has a full copy of the repository and can exchange changesets freely with any other participant. Examples include Git, Mercurial, Bazaar and darcs.
This stands in contrast to a centralised VersionControlSystem, where there is only one repository stored on a central server, which serves as the hub for any collaboration: participants must push commits to this server and must fetch others' commits from it. This has many drawbacks:
Those accustomed to working with centralized VCSs may view the above as virtues rather than drawbacks; project-management culture has a lot to do with how the differences are perceived. However, it should be noted that DVCSs support centralised workflows just as well as centralised systems do; the difference is that they also support decentralised workflows.
Lack of support for decentralised workflows might seem like a technical way of enforcing a centralised workflow. However, almost every DVCS supports two-way bridging with at least SubVersion, and patch-based distributed workflows are possible with any VCS. The effective question becomes how cleanly history can be tracked, should developers find themselves temporarily having to collaborate peer-to-peer in avoidance of the central repository.