Re: reposurgeon now writes Subversion repositories

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.

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"? " :-)
 
> 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.

> Alternative server-side implementation (via breser):
> [[[
> command="svnserve -t --tunnel-user='Daniel Shahaf'" ssh-rsa ...
> ]]]

Um, does this mean everyone's commits are coing to look like
Daniel Shahaf made them? If not, where is --tunnel-user going to
come from?

> Client-side implementation (via danielsh):
> [[[
> [ -n "${EMAIL}" ] && svn() {
> if [ x"$1" = x"ci" ] || [ x"$1" = x"commit" ]; then
> command svn --with-revprop=svn:x-committer-email=${EMAIL} "$@"
> else
> command svn "$@"
> fi
> }
> ]]]

Bletch. This one is begging for failure unless you can train your
users to use a wrapper script every time - good luck with that. One
important case where this approach will break, and cause acrimony, is
Emacs VC mode. That's somewhere up to 50% of your users under
open-source platforms, if the stats on editor usage are to be believed.

The lesson from this criticism is intended to be that it's not
enough to make Internet-scoped IDs possible, you have to make
them *easy* - that is, not disruptive of normal workflow.

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.

-- 
		Eric S. Raymond