[I reordered some of the blocks from Eric's original to make my reply
flow a little better]
On Fri, Nov 30, 2012 at 1:53 PM, Eric S. Raymond <esr_at_thyrsus.com> wrote:
> When it happens, Subversion as it is now isn't going to be able to
> play. You guys have a three-way design adhesion between authentication
> identity, attribution identity, and local identity on the host server.
> For Subversion histories to be mobile, *that adhesion must be broken*.
No we only have that 3 way adhesion in one configuration. In
particular svn+ssh when you use it with local users.
Even then you can avoid the whole thing by having users log into svn
as a single username, set the svn:author by putting this before the
users ssh key in authorized_keys for that user:
command="/usr/bin/svnserve -t --tunnel-user user_at_example.com" ssh-rsa ...
In fact there is a specialized forge that is using this very
configuration with Subversion, Git and Mercurial:
http://www.wowace.com/wiki/repositories/ssh-public-keys/
> If Subversion wants to continue to have a presence on next-generation
> forges, it's going to have to fix this. DVCSes show us how to solve
> the problem, but it isn't actually about centralized
> vs. decentralized. It's about being welded to a specific host by its
> /etc/passwd vs. being able to migrate.
You can't seriously think that being dependent to local unix users
would be acceptable to the large corporate installations we support?
Obviously we support using separate authentication. I'd say we had it
pretty much from day one since the original server was httpd and had a
huge amount of flexibility in how to do authentication with it..
What's different here is that we don't necessarily separate the
attribution from the read/write authentications. You yourself have
said that you didn't think that was important.
> 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.)
Well if the only solution you find acceptable is that the svn:author
is set from the client side then I think we are talking about
philosophy here. I'm not sure if that's the only solution you find
acceptable but several configuration solutions have been suggested to
let you have usernames that have nothing to do with local unix users.
Received on 2012-11-30 23:42:41 CET