On 05.01.2012 18:25, Mark Mielke wrote: > On 01/05/2012 12:04 PM, Branko Čibej wrote: >> On 05.01.2012 11:32, Julian Foad wrote: >>> 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 ?]. >> 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. > >>> 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)". >> That seems less than optimal. Your specification changes the meaning of >> svn:author. Do you intend this to cater to the installations that are >> already abusing and overloading svn:author? > > As one of these abusers, I don't mind re-writing history to fix this > problem. I don't have a need for catering here. As per the previous > email around the original problem of importing content from GIT, I > don't mind either of: > > 1) Prevent users from setting svn:author:* properties, but if they > happen to exist - to serve them instead of doing a lookup. In this > case, I would migrate historical data using revprops and make > svn:author become the primary key / unique identifier again. > > 2) Migrate users that do not exist into a database of removed users > and have the data available for lookup resolution. > > Either would work fine. > > There is of course some expectations around transition - such as we'd > only want to do the conversion to the new model once some key tools > supported it - "svn log", TortoiseSVN, Subclipse, and Crucible/FishEye > will begin working right away as the content of svn:author is now > recognizable as Crucible/FishEye user identifiers without the need to > define committer mappings and the Subversion metadata could be > re-indexed. I think it wouldn't be a problem beyond scheduling. > Well, given that revision properties aren't indexed at all ... my use of the term "primary key" was a bit overdone, since it's really just a convention, not a requirement. But If we extend the way we identify authors, we'd better do something about enforcing these requirements, too. -- Brane
