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
Received on 2012-01-05 18:34:44 CET