Branko Čibej <br...@wandisco.com>:
> Well, I find that we don't actually spell out anywhere that svn:author
> can be pretty much any UTF-8 string. It can even contain newlines,
> although that's not recommended.
No kidding. That's an edge case *I* surely wouldn't want to screw with.
> Hint: svn commit --with-revprop svn:author="Twizzle Strongpants
> <ts@interwebs>"
Iiiiinterressssting.
> I'm open to suggestions, up to and including breaking that assumption,
> though obviously I'd prefer not to.
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.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
