On Fri, Nov 30, 2012 at 12:51 PM, Eric S. Raymond <e...@thyrsus.com> wrote: > I'm not sure what the entire right design fix for Subversion is here, but > I *am* sure you guys should be paying attention to this now so you can have > the fix ready and deployed by the time forge evolution makes it urgent, which > I would say will be on the close order of three years out. Sooner, if I > actually get to pay concentrated attention to the problem. > > So think: What would it take to divorce identity-for-attribution from > identity-for-authentication, making the former user-settable the way > DVCSes do? The challenge, of course, is doing it upward-compatibly. > > I apologize for not being able to make any concrete suggestions here; > outside of the dumpfile format I don't know your code and protocols > well enough.
I'm not sure it's something we want to change for everyone. I suspect you're the first person that's ever raised any complaints about this. This is really a philosophical difference between a centralized version control system and DVCS. Depending on your repository access setup there are ways around this. If the server side knows the value you want to put in svn:author instead of the authenticated user name then it's pretty trivial to fix with a hook script. In my opinion the thing to do here is to allow auto revision properties (possibly on a per repo/server) basis. Then we could pass along some user configured extra value with each commit and server admins could decided to put a hook script in place that puts it in svn:author if they wanted. If that's something we want to do as a project or not I don't know.
