[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: format of svn:author

From: Stefan Fuhrmann <eqfox_at_web.de>
Date: Mon, 09 Jan 2012 03:55:23 +0100

On 04.01.2012 19:42, Julian Foad wrote:
> The extended author fields are delivered through revision properties. The values are UTF-8 text. These revision properties are readable but not writable by clients.

Maybe, I missed something in your post but I want
to stress that is very important to be able to change
that information later on.

One use-case is a repository move, another are
changes to the user accounts themselves (had
that more than once in the past). Because typical
pre-revprop-change scripts will compare the
current user with the rev's creator before it accepts
log message changes, an update of old user info
seems necessary.

Once we are at it, a server-side tool for efficient batch
user changes would be nice (millions of revprop
changes distributed over multiple repositories).
> Three property names are initially designated as "well known":
> * prop name: "svn:author:authn-id"
> purpose: authenticated user id
> format: as used by Subversion's authentication (the default
> value of svn:author)
> * prop name: "svn:author:display-name"
> purpose: display name
> format: a single line (no line breaks), e.g. person's full
> name or shortened name or nickname
> * prop name: "svn:author:email"
> purpose: email address
A general observation: It seems impractical to store
anything but the user / account information. The
strategy would be to hope that one of the 3 aspects
of a given account will not change over time.

Modelling a real person with such aspects like having
different accounts at the same time (happens in
sufficiently large companies) seems to be out of scope
entirely. It would open a whole new can of worms.

The deeper problem behind all this is that we record
the history of ones user management and not only
apply the the current, consistent account settings.
Introducing ACLs within SVN at some point in the
future will probably make that issue much more obvious.

-- Stefan^2.
Received on 2012-01-09 03:56:06 CET

This is an archived mail posted to the Subversion Dev mailing list.