A superset is not always better.

Consider domain-specific languages vs. general-purpose languages. You need to weigh the benefits of increased power with the drawbacks of additional complexity.

Ease of use is important, we certainly agree on that. But "git clone url" vs "svn co url" and "git commit -a" vs "svn commit" isn't significantly more complex.

Centralized VCSes can lock files. DVCSes cannot. Ergo, DVCSes are not a superset of centralized VCSes.

Couldn't the upstream repository just not accept changes to that file? I'm sure this could just be managed by some kind of commit hook.

Interesting. I hadn't considered that possibility. I'm more familiar with hg than with git, but from what I gathered in #mercurial, it should be possible to write a combined extension + a commit hook that:

* allows people with appropriate permissions to lock and unlock files

* sets locked files to read-only on pull from the canonical repository, so that users are warned beforehand that the files are locked

* rejects commits that modify locked files except for by the person that holds the key

There are a bunch of issues that need to be worked out, but I think the problem is tractable. Nice, thanks for the idea!