Ben Reser <b...@reser.org>:
> This is really a philosophical difference between a centralized
> version control system and DVCS.
No, no, no. If you think that's true, I have failed to communicate.
I'm not handwaving about philosophy. I'm pointing at a specific
problem that comes up when you start thinking of an entire software
project's state as a data object that you should be able to move
around and re-instantiate on a different forge server. By "entire
state" I mean repositories, bugtracker contents, mailing list and
forum messages, and member capabilities (who is an admin, who is a
committer, etc.)
Motivation: we *want* project state to be mobile because relying on
any given forger server to be stable forever is too risky. On decadal
timescales this is a real, serious problem. Berlios's near-collapse
sensitized me about this.
The problem is that in order for that state to be mobile, none of it
can have pointers to data that can't move off the host server. In
particular, *all user identities have to be Internet-scoped* rather
than local Unix IDs. Otherwise, when I try to move project foo to
server bar, there will be friction in the form of potential name
collisions that are messy to resolve.
It turns out when you dive onto this problem (and I have) that Unix
user IDs are *the* blocker. There's almost nothing else in a forge's
ontology that can't be resolved in a fairly trivial way. The only
exception is that project names themselves may collide.
The next generation of forges is going to have to fix this problem.
And it actually isn't terribly difficult to fix - it's creative
engineering, but not blue-sky R&D. I could certainly implement it,
and I will if I can budget the time. I've done a lot of the design
work already.
When it happens, Subversion as it is now isn't going to be able to
play. You guys have a three-way design adhesion between authentication
identity, attribution identity, and local identity on the host server.
For Subversion histories to be mobile, *that adhesion must be broken*.
If Subversion wants to continue to have a presence on next-generation
forges, it's going to have to fix this. DVCSes show us how to solve
the problem, but it isn't actually about centralized
vs. decentralized. It's about being welded to a specific host by its
/etc/passwd vs. being able to migrate.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
