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.
>> 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.
--
Mark Mielke<mark_at_mielke.cc>
Received on 2012-01-05 18:26:09 CET