This discussion has been fruitful. The responses from Greg, Branko
and others suggest that you guys are actually engaged with the
project-mobility problem now - apologies if my approach seemed a bit too
boot-to-the head, but I really am trying to be helpful.
I think I can now write a simple proposal that will work.
Despite what some people in this conversation have thought, I'm not
ideologically fixated on "user sets his own attribution ID". But
I keep coming back to that because it seems to be the only solution
that scales up and covers all the deployment cases.
Here's the proposal:
1. Add support to the client tools for shipping a FULLNAME field
mined from somewhere under ~/.subversion. Maybe the existing
username entry will do, maybe it won't - I see arguments both ways.
I don't care, we can fill in that detail later.
2. Add server-side logic that says: if you see a FULLNAME field
in a request, use that to fill svn:author. (Yes, in practice
you used a different, dedicated revprop to carry FULLNAME.
That's OK, it's an implementation detail.)
3. Add a config switch to the server side that tells it to reject
commit attempts with a "Set your FULLNAME, please" message if it
doesn't see a FULLNAME field in the request. Initially default this
switch off.
4. (Important) Tell repository administrators about this in the docs,
and say that turning on FULLNAME-required is best practice, and
explain why. Since I know how much most people hate writing docs,
I volunteer to do this part.
5. If you're really worried about spoofing, you add some server-side
logic that stores (auth-cookie, FULLNAME) pairs whenever a new
FULLNAME arrives and barfs if a known auth-cookie arrives with a
known FULLNAME and they don't match. But this is an optional extra,
field experience says you don't need it.
There. You're done. It's backward-compatible (older installations
can ignore the feature and nothing breaks). It's independent of your
authentication method, but you can add auth checks if you care enough.
It scales well because the burden of setting up FULLNAME strings is
small and distributed - also because project administrators only have
to make one decision, once.
I'm not certain, but if your server-side hooks work the way I think
they do, all of this except (1) can be done in Python. Not having to
add complexity to your C code is a significant virtue.
If you have an LDAP setup or something like that, you don't need this
- you flip some other switch once and stuff Just Works. Which is fine:
the point of this proposal isn't to force a DVCS-like choice, it's to
put in place a low-effort path to Internet-scoped attribution IDs that
will *always work*.
Somebody alleged "this is a social problem". That's only half-true, but
now I'm going to focus on the true part. "Social problem" doesn't
mean you can or should ignore it. It means you have to lead by
educating and jawboning your users. A large step is just being willing
to say, where your users can see it, "Internet-scoped attributions
are important. Here's how to make them work..."
--
Eric S. Raymond
Whether the authorities be invaders or merely local tyrants, the
effect of such [gun control] laws is to place the individual at the
mercy of the state, unable to resist.
-- Robert Anson Heinlein, 1949
Received on 2012-12-01 14:53:50 CET