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
