"Eric S. Raymond" <esr_at_thyrsus.com> wrote on 11/30/2012 03:53:45 PM:
> Ben Reser <ben_at_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 foo_at_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.
Received on 2012-11-30 23:23:12 CET