(Sorry, still feeling a bit verbose.)
[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.
> 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.)
> 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. Once again I think it is
your old Unix wizard thinking that leads you to forget that for the
vast majority of Internet-connected clients out there, there is no
/etc/mailname, no local MTA, and the best auto-generated email address
is going to be some "user@foobar.localdoamin". Which obviously fails
points 3 and 4.
This isn't a theoretical "but what if someone ran svn on their Android
phone?" Subversion has high penetration in corporate Windows shops,
where the best way to figure out your email address may be to look for
a local Outlook installation. (Yes, Active Directory uses DNS domain
names, but in my experience they are usually internal - morally
equivalent to ".localdomain".)
And it's not like locally scoped or unroutable FQDN's are specific to
Windows shops. In git commits, I see plenty of domains that look like
random hostnames that likely won't have MX records.
What I'm getting at is, when considering whether to configure something
on the server vs. the client, don't assume that the client can just
automatically fill it in. That'll work for the likes of you and me,
running on Unix boxes with configured MTAs, but for most Subversion
users, you'll be asking them to _explicitly_ configure their info. 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.
* * *
> > Now, of course, it's possible that some people would want a more
> > structured way to express the _author_ as opposed to the _committer_.
>
> I consider this (how to amend the attribution model) an orthogonal
> issue. It's a whole different discussion into which it would be best
> not to get sidetracked.
Agreed. The only reason I brought it up is because I thought perhaps
one reason you wanted an identifer to be tied to a commit, rather than
to a committer, is because you were thinking about the original author
problem.
Peter
