Ben Reser <ben_at_reser.org>:
> But again, if you want svn:author to be set to some value a user sets
> locally and that has doesn't necessarily have anything to do with
> their authentication to the server, you can't do that with username
> configuration. Since there is absolutely no guarantee that username
> will even be sent to the server.
Alas. I hear you reporting that identity-for-attribution and
identity-for-authentication are not cleanly enough separated for the
user to be able to reliably set the latter to a chosen Internet-scoped ID.
Subversion is still off Federation's list, then. This may not matter
in itself, as Federation only exists as design ideas at present. But
I strongly believe future forges are going to go in the direction I'm
pointing, even if it doesn't happen to be me leading the way. The wins
from being able to marshal and cross-load project states are just too
large to be ignored much longer. And Subversion as it is now won't
be ready to play in that world.
I'm not sure what the entire right design fix for Subversion is here, but
I *am* sure you guys should be paying attention to this now so you can have
the fix ready and deployed by the time forge evolution makes it urgent, which
I would say will be on the close order of three years out. Sooner, if I
actually get to pay concentrated attention to the problem.
So think: What would it take to divorce identity-for-attribution from
identity-for-authentication, making the former user-settable the way
DVCSes do? The challenge, of course, is doing it upward-compatibly.
I apologize for not being able to make any concrete suggestions here;
outside of the dumpfile format I don't know your code and protocols
well enough.
--
Eric S. Raymond
Received on 2012-11-30 21:51:49 CET