On Thu, Nov 29, 2012 at 5:49 AM, Eric S. Raymond <esr_at_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.
Received on 2012-11-29 18:39:35 CET