kmra...@rockwellcollins.com wrote on Thu, Jan 05, 2012 at 14:03:37 -0600: > Mark Mielke <m...@mark.mielke.cc> wrote on 01/05/2012 12:36:10 PM: > > On 01/05/2012 12:34 PM, Branko Čibej wrote: > > > On 05.01.2012 18:25, Mark Mielke wrote: > > >> On 01/05/2012 12:04 PM, Branko Čibej wrote: > > >>> Ha, but svn:author currently fills that role. So why add another > > >>> property? > > >> If svn:author is defined as the primary key and also the > > >> authentication key, it does seem simpler and more compatible with > > >> existing tool assumptions and existing documentation. > > > svn:author is basically "the username". Of course, many installations, > > > especially those that use client certificates, will put other things > > > there; an example I've ofthen seen is CN (Email), which usually is not > > > what you'd really want since neither is unique or persistent. > > > > Yep. Microsoft AD likes to use user's name in the DN (Distinguished > > Name), or at least that is how many people seem to configure it. Yuck. > > In any case, I would say it's the responsibility of the organization to > > decide what their unique identifier is. If they choose a bad one - > > that's on them. :-) > > > > For many systems, username is pretty good. > > Coming late to the discussion, but assuming you are using apache, > one could use an existing (or custom) auth module in apache > to mangle/rewrite/map the provided user id that subversion > uses to something that may be more useful. Subversion will > then happily store whatever is provided in the author field. > This would purely be a server side configuration.
You can do that in the pre-commit hook too.