On Thu, Nov 29, 2012 at 5:49 AM, Eric S. Raymond <e...@thyrsus.com> wrote: > I say break the hell out of it. The utility of Internet-scoped > attributions is pretty high in a bunch of different ways (I love me > some Ohloh statistics, there's one). And I doubt "server > verification" actually buys you much. Whetever it does buy you you > can keep by sticking the "verified" username in a property that > auditing tools can see but users don't need to. > > Let me give you a major forinstance. I have been seriously thinking > for a couple of years about writing a better software forge. Many and > various are the ways in which the existing ones all suck, but the > single worst problem with them is probably that migrating project > state between instances ranges from hard to impossible. > > For reasons I shouldn't neecd to explain, we really want to live in a > world where a forge instance that's about to undergo planned shutdown > can squirt its project states to a bunch of peers and have each one go > seamlessly live on a new host. If the forge federation is designed > right, users shouldn't even have to know when this happens. > > So, guess why I had to cross Subversion off the list of VCSes my design > would support? Yes, that's right - system-local usernames in the forge > database and VCSes are the single most severe point of adhesion. I had > to get rid of them entirely, just as DVCSes have. > > Subversion should do likewise.
But as people have already said the meaning of the svn:author field is locally defined by the repository. There is nothing preventing your proposed software forge from defining that the author field is some different type of value e.g. the users email address. Heck the book even says that you shouldn't assume that svn:author is even set (believe it won't be set if you allow anonymous commits): http://svnbook.red-bean.com/en/1.7/svn.advanced.props.html The only thing that's really lacking here is a good way to pass along extra property values in an easy to configure way per server/repository so that you can use a client defined value to put it in svn:author. I don't really see adding support for something like that as terribly difficult. The only caveat I would make is that you should realize the change here is a client side change and that it'll take some time for users to upgrade clients (most distros are still shipping SVN 1.6 over a year after 1.7 released). Once you have something like that, you can expose it to the hook scripts and they can change the svn:author field to whatever the local repository prefers. If local repositories want to store the local authenticated user in a different property they can also do this. Given your goal that users shouldn't notice I'm going to assume you're allowing anonymous commits. Right now there's really no definition of how svn:author behaves with anonymous commits. So I'd say that it would be perfectly reasonable to define such a configurable value and default to filling svn:author with it in the case of anonymous commits.
