On 01.12.2012 14:14, Eric S. Raymond wrote:
> (Apologies if this is a duplicate send. I just had a disturbing
> glitch in my MUA and want to make sure it got out.)
>
> Daniel Shahaf <d.s_at_daniel.shahaf.name>:
>> Server-side implementation, independent of RA method: (via brane)
> Ah, now that looks somewhat like progress. But some (possibly all) of
> these solutions have serious weaknesses which you need to think about.
>
>> [[[
>> #!/usr/bin/env python
>>
>> import sys
>> from svn.repos import *
>> from svn.fs import *
>> from svn.core import SVN_PROP_REVISION_AUTHOR
>>
>> FULLNAMES = {
>> 'danielsh': 'Daniel Shahaf',
>> }
>>
>> reposdir, txnname = sys.argv[1:3]
>>
>> repos = svn_repos_open(reposdir, None)
>> fs = svn_repos_fs(repos)
>> txn = svn_fs_open_txn(fs, txnname, None)
>> propval = svn_fs_txn_prop(txn, SVN_PROP_REVISION_AUTHOR, None)
>> svn_fs_change_txn_prop(txn, SVN_PROP_REVISION_AUTHOR,
>> FULLNAMES.get(propval, propval), None)
>> ]]]
> This one confines your Unix-ID adhesion to the FULLNAMES array, which
> is a long step in the right direction because it means your repo history
> will be local-ID-clean.
>
> But it doesn't actually solve the mobility problem. If the project
> ever moves, you still have to patch the FULLNAMES dictionary by hand.
> This approach won't scale very well.
Oh come on. Daniel was giving an example cobbled up in all of 5 minutes.
Surely you can imagine replacing FULLNAMES with some user database?
> I also note that you do really want "J. Random User <jrandom_at_foobar.org>"
> with a preferred "home" address as part of the mix, because the
> entropy of human names alone is not quite high enough. Yes, if I see
> "Daniel Shahaf" I'm pretty sure there is only one of those. But
> "Willam Smith" or "Robert Jones"? " :-)
See above. You can put anything into FULLNAMES and/or a database and/or
LDAP (which is just a database).
>> Alternative server-side implementation (via markphip):
>> [[[
>> AuthLDAPRemoteUserAttribute cn
>> ]]]
> A variant of this that does "J. Random User <jrandom_at_foobar.org>"
> looks like it might work provided there's an LDAP directory and we trust
> the LDAP directory to be up to date. The second assumption seems
> reasonable if we grant the first.
>
> But the first? I've heard of LDAP and know roughly what it does, but
> I've never seen a live instance. Forges don't have them. Maybe I'm
> being parochial, but this seems like a solution for a case too unusual
> to be very interesting.
Oh right. Does it make the solution any less unusual if I tell you that
all of the ASF services, including Subversion, have single-signon via
LDAP? Or that you can just as easily replace mod_ldap with
mod_authn_<database-of-choice> which essentially brings you back to the
post-commit hook example.
> But this has been fruitful. I think I can write a simple proposal
> about how to solve this problem now. I'll do it in my next email.
No offence, but it sure looks as if you're deliberately nitpicking in
order to give yourself an excuse for writing a proposal for a feature
that Subversion, essentially, already has.
Certainly I'll read your proposal and don't intend to dismiss it out of
hand. But trusting the server to properly authenticate committers is a
basic axiom of Subversion's centralized model. And for the record, it's
also a basic axiom of GitHub's centralized model.
-- Brane
P.S.: I find it fascinating that DVCS aficionados haven't noticed that
GitHub takes the D out of DVCS very effectively, thereby making git
actually useful for most normal people.
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2012-12-01 15:24:39 CET