subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Mielke <>
Subject Re: format of svn:author
Date Thu, 05 Jan 2012 17:25:34 GMT
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<>

View raw message