subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <julianf...@btopenworld.com>
Subject Re: format of svn:author
Date Thu, 05 Jan 2012 10:32:15 GMT
Branko wrote:
> [...] you have to define which of the properties must  have values
> that are unique within the given repository; what is the primary key;

OK, let's say:

The "svn:author:authn-id" value is the primary key, and so is unique within a [Subversion
repository | Subversion server ?].  The administrator must configure the Subversion server
to perform a mapping from "svn:author" value to the primary key, typically the trivial "x
-> x" mapping but another example could extract "1234" from "John Doe (1234)".

This specification does not require the values of any other extended author field to be unique.

The administrator may guarantee locally that a particular extended author field is unique
in some scope.  For example, a build-bot can update an issue tracker, and so needs to know
the issue tracker user id for the author of a particular Subversion revision.  The administrator
configures Subversion to provide that id in the "author:tracker-uid" revision property. 
The issue tracker user id needs to be unique among all users of the tracker, of course, and
so the administrator ensures that is true and then tells the build-bot which of Subversion's
extended author fields holds the issue tracker user id: that is, "author:tracker-uid".  Note
that its values are unique among all users of that issue tracker, not necessarily the same
as being unique across all users of a particular Subversion repository or all Subversion repositories.


> and how to select the property to be shown in log, blame, and the like.


That is briefly stated in the "CLIENT DESIGN" section -- basically, client-side configuration. 
(Client-side configuration is of course not ideal, but is a stepping stone to server-dictated
configuration which is the subject of a separate and concurrent design effort.)



Mark Mielke wrote:
> On 01/04/2012 01:42 PM, Julian Foad wrote:
>>  A PROPOSAL FOR EXTENDED AUTHOR IDENTIFICATION
>> 
>>  USE CASES
>> 
>>  1.[This one I am aware of.]
>> 
>>     A large company has authenticated user ids that are numeric.  That 
>> means the "log" and "blame" information shown by most Subversion clients 
>> is not easy to understand.  Therefore they use a (post-commit?) hook to 
>> change  the svn:author property to a more friendly string, which (mostly) 
>> solves the display issue.  However, it causes other problems.  [What 
>> problems?]
> 
> Problems:
> 
> 1) The unique identifier is no longer a direct match against external identity 
> management systems. [...]
> 
> 2) Users may end up with multiple unique identifiers over time [...]

So, basically putting display information in svn:author may not cause a problem in that scenario
alone but will cause a problem if and when other tools want the value to be a unique id.


>>  2. [This one is a guess.]
>> 
>>     The leader of a small development team sharing a Subversion repository 
>> with other teams wants to set up a build slave that will send an email [...]
> 
> Much of the above can be accomplished today as it is server side [...].
> To extend the above to a situation that makes it more difficult -

Actually I meant UC2 to be a client-side problem like you're describing, so we're both talking
about the same thing.

[...]

To everything else you said: yes, sounds good.

- Julian

Mime
View raw message