"Eric S. Raymond" <e...@thyrsus.com> wrote on 11/30/2012 03:53:45 PM: > 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.
Possibly I'm naive, but a client provided email address is far from being a GUID. In fact, I can pretty much set my email address to anything in most DVCS tools. Who is to say I haven't used your email address when committing? I can easily imagine something replacing internet email at some point so f...@here.com might be pretty much meaningless in decadal scale. Subversion allows the server hosting the data to authenticate and then manipulate the author id how it sees fit. Using your federation you could easily enforce the author field for the hosted Subversion repositories to be an email address, if that meets your "internet scoped" concept... This would preclude any random Subversion repository, but that same limitation would apply to any random DVCS data as well. Relying on an user provided value to be globally unique seems like a bad idea. I must be missing something obvious... Kevin R.
