[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: format of svn:author

From: Mark Mielke <mark_at_mark.mielke.cc>
Date: Thu, 05 Jan 2012 12:25:34 -0500

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

This is an archived mail posted to the Subversion Dev mailing list.