Peter Samuelson <peter_at_p12n.org>:
>
> (Sorry, still feeling a bit verbose.)
Yeah, like *I'd* have any room to criticize on that score... :-)
> [Eric S. Raymond]
> > 1. They have enough entropy that collisions aren't a practical problem.
> > A human name alone does not. I'm excluding deliberate spoofing from
> > the analysis because we now have enough experience with un-cryptosigned
> > commits in DVCSes to say that this effectively never happens.
>
> That's fine. I do note that, as others have also noted, email
> addresses are not stable over time (yes, your domain from 1985 _is_ a
> special case!) so there may be a desire to retroactively update old
> commits. Though I suppose that hasn't proved to be a problem in
> git-land, where by design, every revprop edit implies a rebase, and
> thus it's hard to do them once your code is publicly visible.
Indeed. One of our advantages here is that we can see what the DVCS
people did, and notice both where they had problems and where the
expected problems failed to materialize.
As the author of reposurgeon - which can edit old commits in multiple
VCSes - I've probably heard more about the use cases for this ability
than anyone else. Patching committers' past email addresses is not
one of them, though I have done that incidentally during a few
repository lifts.
I think this tells us that, at least among the committer population
associated with well-established projects, stable email addresses are
the norm.
> > 2. Because of (1), they allow repositories to be mobile as a
> > disaster-recovery hedge. I've already explained this in detail and
> > won't rehash it except to remind everyone that mobile != distributed
> > - I'm not trying to morph Subversion into a DVCS.
>
> Basically I guess you're saying if contact info and other ID metadata
> live in an account database, that is inferior to living in the
> repository directly, as the repository is more likely to be backed up
> and restored than the associated accounts. Fair enough, but if you
> want the original committers to still have commit access on the target
> site, you'll need _some_ way to import the account database. (Or I
> guess do what we did when we moved to apache.org: tell every committer
> "register yourself a new account here and we'll add you back in to the
> system." But that is not ideal.)
I started to reply to this in great detail. Then I deleted that text, because
none of that is actually very relevant here - it's off into the territory
of how to design a forge that doesn't suck.
I'll just say this: forges, too, will move in a DVCS-direction that
falsifies some of your basic assumptions here. That will happen
quickly if I get to budget time for building Federation, more slowly
if we have to wait for other people to catch up to my thinking.
> > 3. They imply an email pointer back to a responsible person for each commit.
> >
> > 4. They function as Internet-wide primary keys for reputation systems.
>
> As you noted, these two have similar requirements even though they are
> separate use cases. And I actually think this is where client config
> falls apart, or doesn't scale, or whatever.
> And if you ask most admins what "scales better", I bet many of them would
> say something that is entered at account setup time, rather than
> something you have to ask your users to configure on their laptops.
If this were really a showstopper, none of those environments could use
DVCSes. We know empirically that the latter is not true.
--
Eric S. Raymond
Received on 2012-12-05 02:35:46 CET