kmradke_at_rockwellcollins.com wrote on Thu, Jan 05, 2012 at 14:03:37 -0600:
> Mark Mielke <mark_at_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.
Received on 2012-01-05 21:45:34 CET